[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <412B7319.5000705@sdf.lonestar.org>
From: bkfsec at sdf.lonestar.org (Barry Fitzgerald)
Subject: Windows Update
joe wrote:
>The client is required. I have sent a complaint to MS though concerning the
>idea that the service set to manual but started doesn't allow the updates to
>occur. That, I agree, is a bad design choice.
>
>If the service is set to automatic but not started, it will get started as
>soon as you try to actually search for updates. Having it set to auto and
>not started just gets you past the initial check. I actually replaced the
>service with a quick "do-nothing" service I wrote and the web page gets past
>the initial check but then hangs in the search for updates section. I have
>no doubt that the client is actually used and needed.
>
>Once again, I agree requiring the service set to automatic is poor. Again
>however, this isn't life threatening or insecure, just a pain. Simply use
>something to quickly change the start config for the service before going to
>the windows update site and change it back afterward. No big hoo hoo.
>
> joe
>
>
>
>
I would actually go so far as to say that if this is true, it's actually
(most-likely) more secure than relying solely on the activex control.
If the on-system client can be securely queried for the list of updates
that the system needs, this does two things in my estimation: it keeps
the code to do so out of browser-related control and it keeps any
unneeded info from being sent back to MS. (which is good for MS because
it reduces their resource load.)
If they had based their detection engine on proper tests of client
activity, I think this would have removed the confusion here.
-Barry
p.s. Probably the best design is that it should start the client
temporarily when set to manual and then have it fall on it's sword when
the update is done.
Powered by blists - more mailing lists