unity-design team mailing list archive

[Jim Rorie <jfrorie@xxxxxxxxx>]

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.