unity-design team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

On 24/04/10 15:20, Jim Rorie wrote:
> 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.

I think there might have been three days in the last six months when
there were no updates to Lucid. It would make more sense to notify you
that there are NO updates today, than that there are updates :-)


>   If there ever was a reason for a notification, it would be
> updates.
>   

Yes and no. Security updates should be top of mind for the user, and
yes, that means having them a little in your face.

Other updates are really irrelevant. They come along, you should do them
every now and then, but they are not worth interrupting you for. If you
wanted them sooner, you could subscribe the the -proposed PPA, if you
wanted them later, you could update monthly, it really doesn't make that
much difference *to the average user*, and failing to see that makes
this conversation very difficult.

> 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.
>   

Again. Updates are not a regular task for regular users.

I appreciate that you're passionate about the latest builds. If you were
*more* passionate, you might be subscribed to a few of the daily PPAs
for packages you're really interested. But all of this makes you part of
the tiny minority of users for whom this is a matter of some excitement.
It makes you important to us, which is why I'm taking the time to answer
this for the umpteenth time, but it is not a passion we should expect
end-users to share.

> 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.
>   

Calm down please. Melodrama won't bolster your argument.

Some security updates are not active until you reboot. Period. If there
is a security problem in your kernel, you need a new kernel, and you
need to boot it. We're done a lot of work to minimise the number of
cases where that's important, but I'm not aware of any way to eliminate
the occasional requirement of a reboot.

> 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.
>   

I do believe there is a proposal along these lines in the works, MPT
would comment in detail. It does not make sense to offer this on resume
or unlock, as the user is at that point clearly anxious to get going,
not wrap up. But nevertheless, yes, there are times when it is useful to
offer the option to do something about updates, and we'll do so.

>> 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.
>
>   

But your arguments are not entirely persuasive :-)



>>> 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.
>   

And you think malware couldn't put up a systray icon tricking you into
thinking you have updates? You think you would be able to tell the
difference? The panel icon is just as fakeable as the popup.

Mark

Attachment: signature.asc
Description: OpenPGP digital signature