>>> The reason it is not designed like this is for security. If firefox >>> stores it's passwords in a keyring ( it doesn't yet ), and you download >>> random spyware/virus from the web and launch it, with the cookie jar >>> method the rogue program would have access to all your web passwords. >>> Right now you would get a pop up, or maybe twenty that ask if that >>> random program should be allowed to get this information. >>> Firstly Jon,
Though I wouldn't want to suggest the one-keyring thing is the correct solution here, I don't understand your point about Firefox. With this hypothetical feature: Surely any spyware/virus running as/under Firefox would have access to all keys that Firefox had access to regardless of whether they are all authorised to Firefox as a group or each individually. Alternatively if the spyware/virus were a separate process then one would expect get a message saying "Do you want to allow this spyware access to your entire Firefox keyring?" just as one would get individual messages now. Or do I miss something important here? Pat, While developing/testing this interface you must must be creating/editing/ deleting many keys/configs over and over again. But, I wonder how often a user is likely to do such bulk editing. One hopes that the NM+ the applet will at least get most stuff right most of the time. As far as a solution, it seems that any a process that is authorized to use a keyring, and authorized to edit/use a specific key also has the right to give other applications permission to use a key. Perhaps if this became a significant problem and once the location of your tool has solidified a little, the applet could upon creating the key also authorize the edit tool? This implies some kind of trust between the two binaries and as Jon describes this would be a question of balancing usability with security. tOnY _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
