Devdatta wrote:
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.
The study says that extensions use nsIFile to 'store information that
is too complex for the preferences system'. What is 'too complex' ? If
a key value store (viz. the preferences system) isn't good enough,
would localStorage work ? Do you have a list of extensions for whom
localStorage would be good enough (but can't work with just the
preferences system) ?
For non-Jetpack extensions, places like #extdev have been explicitly
telling people to avoid prefs for larger scale storage, because prefs
are always completely loaded on startup (so things like a table for a
site-specific extension wouldn't make sense. localStorage would work,
but then again the extensions could already access the sqlite storage
(https://developer.mozilla.org/en/Storage) stuff anyway.
(I must be odd, since about half my extensions don't interact with the
content page being viewed, and I don't think any of them is doable with
the current Jetpack API...)
--
Mook
(I do extensions and poke xulrunner apps, as a short background.)
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
