On Tue, 2006-06-27 at 13:58 -0400, Pat Suwalski wrote: > Jon Nettleton wrote: > > 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.
Take a deep breathe...phew now isn't that better. > > > Then FireFox wouldn't use this functionality. They would ask one key at > a time, like the current implementation does. But it should be possible > for a program to ask for access to a whole keyring. That's why it's > called a keyring: you typically hand the entire ring to someone, not > just one key. It is called a keyring because it holds many keys. Personally I generally only give a person a single key from my keyring. When someone is borrowing my locker at the gym, I also don't give them the keys to my house and car at the same time. Semantics I know but let's keep our perspective about the problem. > > For wireless security, it's even sillier: I thought it ridiculous when > the XP SP1 interface started hiding the WEP key being entered. Only > hiding the password on a proper certificate makes any sense, as that is > actually personalized data, often based on a real login u/p. > > Security gets in the way of a good user experience far too often under > Linux. This is why things like NetworkManager exist. You say this and yet how many voices cried out in anger when NetworkManager started using gnome-keyring to store their keys. The balance between security and usability is a give and take process. We are all doing our best to make things work as seamlessly as possible without ending up with Windows 98. > > Regardless, it would be nice to have the keys in a separate keyring so > that they're grouped together. Maybe some day it will be possible to > access the entire keyring. > > > Then interface that I started working on for the ACL dialog doesn't > > completely fix this problem, but intends to reduce the confusion. > > Envision that for a single application to access all items in a keyring > > you will get a dialog that pops up that has all the items listed with > > checkboxes next to them. Then you will have buttons for allow to > > selected for this session, always, deny. Anyways you kind of get the > > idea. > > This doesn't help me much, since I don't necessarily want to load all > the items at once. In fact, because this is a separate process, I want > to load as little as possible to prevent a local cached copy of the data > going out of sync with nm-applet. > > I see it as: > - User starts editor > - gnome-keyring asks for access to 'wireless' keyring > - As user clicks around, information is loaded on an as-needed basis > > Right now it's like this: > - User starts editor > - If first AP in list is not WEP-less, they get a gnome-keyring message > asking for password/access. > - They click on the next item, the above step repeats. > > From a user's point of view, it borders on ridiculous. "Just give this > program access to all the wireless keys, dammit!" is what they'll be > wishing for. > > Your approach would not be very useful to nm-applet either unless it > loads all the encrypted networks in one shot, which I don't think is a > very good idea. It also makes it a heck of a lot more work to make the > editor apply changes in a way that they are visible to the applet. I am sorry to have wasted your time I did not understand from your other emails what your use cases were. My suggestion would be to file a RFE bugzilla at bugzilla.gnome.org. > > --Pat _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
