On 9/6/11 8:46 AM, Walter do Valle wrote: > I know that script. However, as I said in my original e-mail, it fell in > some security issues. It's not possible to call this script without > requesting some privileges. And that request generates an "ugly" dialog box > asking user about permission. I need something more transparent. > I assume that: if my Java applet is digitally signed and user agrees running > it, it should call any javascript without requesting additional permission. > Is there any other way?
Isn't that effectively the same thing since both ask the user to grant permission? Is there more difference than the aesthetics of the permission dialog? Anyway, we've deprecated enablePrivilege and will remove it in the future so ultimately that's not an option. Finding the profile directory is a potentially dangerous thing. The path itself might leak personal information, and not knowing the profile directory is sometimes the only thing standing in the way between stealing your passwords/bookmarks/cookies or not should someone find a security bug that allows file stealing. Therefore it's always going to involve some kind of checking with the user. Java applets granted permissions can do a lot of awesome things on their own, but if they call back into the page the scripts in that page are still going to be limited by the permissions of the page. You could try to find the user's profile yourself in Java by writing platform-specific file code to emulate the Firefox code, but if the user has multiple profiles or has picked a non-standard location you're pretty stuck -- back to asking again. Your best bet, honestly, is to ask users to install a restart-less add-on (search for "Jetpack" or "Add-on SDK" at developer.mozilla.org). Installing the add-on is about as much bother for the user as the Java or JavaScript permission dialogs, and users already understand the concept of installing and won't get confused as they might with the unfamiliar permission dialogs. And they know how to later revoke the permission (uninstall) as opposed to a remembered choice on a JavaScript/Java prompt should they need to do that. Once you have an add-on you have all the privileges you need (so your code has to be careful, of course!), including easy access to the user's PKCS11 modules. This will be far easier than trying to extract the certs from the database from external Java, and more robust as the certificate store changes file name and/or format in the future. Will even handle the case where the user's certificates are on a smartcard which your java file-reading approach won't. -Dan Veditz _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
