On Fri, 2010-04-23 at 09:56 +0100, Mark Shuttleworth wrote: > I appreciate the desire to defend the users flow. That's a value we > share. But being dogmatic about that won't get the best result. We > should be sparing about interruptions, so that when we do them, people > pay attention. And we should be very careful about the message we > convey, so that we minimise the interruption and maximise the chances > that people will do the right thing.
But you are penalizing the very people that are helping you. I can't install updates automatically because I'm typically running a late alpha, beta or RC to help Ubuntu test it's product. Or I'm on development machine that can't afford to go down because of a badly tested patch. Under your current proposal, here is what I'm supposed to do. 1) Poll updates since I have no indicator. This is a complete and total fail, IMO. If there ever was a reason for a notification, it would be updates. 2) I have to dig through the menu to trigger updates(Hmm, is that preferences or administration? I can never remember). Annoying for a regular task. 3) You are going to pop down a dialog on my desktop if I fall off the hamster wheel, much like porn spam. And open a security hole. (More later) 4) You are going to reboot my system some percentage of the time, thus further interrupting my workflow. This is INSANE! I'm a committed user that understands the magnitude of security patches and updates to the point to be able to assist in bug reporting. And I'm being punished because someone felt people didn't understand the update notifier. And now you want to take away my usability hack. A sane solution: When the user shuts down, reboots, suspends or resumes(or the screen saver if they have suspend turned off), trigger the dialog to ask about updates (or provide a button to automatically do them) The system will do the task, reboot/reset or whatever without interrupting the workflow. These events happen multiple times a day so they are timely. If someone says no like 20 times, then you can annoy them. But they probably are going to say no then too. > That's what MPT is arguing for. Your response is "the crux of the > problem is the asynchronous window". But you're missing the point that > the underlying condition is both serious and asynchronous. My understanding of the problem is both thorough and profound. > > Plus, as I pointed out several months ago, this is a HUGE security hole. > > Passwords should only be given in response to a user initiated > > operation. Asynchronous dialogs that ask for passwords are a very bad > > precedent for a secure O/S. > > > > Best we get those finger-swipe gadgets working, then :-) Not going to solve the problem. And based on that response I think a little analogy is in order. Let's say I want to do a wire transfer. I call the bank. They say cool, but we need your credentials to start the transfer. Since I initiated the call, I am pretty confident that I am talking to the bank, so I give them my password and my money is on it's way. Let's look at another scenerio. You call the bank, but get voicemail. You leave a message saying you'd like to do a wire transfer and hang up. Several days later you get a phone call from a person asking for your bank credentials. The question is, is it the bank and do you give them that information? The first situation is synchronous, the second is asynchronous. This is the problem that you have created. The malware author need no longer hook into an administrative event to fool the user. They simply need to fling a somewhat similar copy on the desktop. In essence you are training the user to respond to any dialog that mystically appears on the desktop at any time. When Ubuntu becomes a security target, it will be a shooting gallery. _______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp