4 ms·

Let's try to think through why they might not want to make it completely automatic without several steps. Hmmm. What downside could there possibly be. Let's

by conor23 14y ago

Let's try to think through why they might not want to make it completely automatic without several steps. Hmmm. What downside could there possibly be. Let's think. Let's think.... Nope, I can't think of any. Oh wait aren't we're actually responding to a post about a vulnerability in the update mechanism, when you say, "not only is it vulnerable, but it should essentially be automatic!" :)

deleted 14y ago
[deleted]
- conor23 14y ago
  Maybe so, but there are a handful of overriding reasons I can think offhand for why you don't make updating more automatic 1) The customer didn't ask. It's their PC, not yours. 2) "Backwards compatibility." See: https://xkcd.com/1172/ https://xkcd.com/1172/ Basically, if you don't leave your program bit-for-bit the same as it was, maybe you break someone's shitty workflow that you could not possibly have predicted and which has no grounding in anything sane. 3) BIG ONE!!! You might have made a mistake. The old version worked fine, for millions of your customers. But you just pushed a version that causes a fairly common setup to have all sorts of problems. How do you protect against this? Well, for one thing, you can make the update process a bit more involved. Track it better. Keep logs. Nip it in the bud. (Meaning when the first few complaints from early adopters - who jump through the hurdles - trickle in. Not millions at once.) That way you won't accidentally screw your whole entire installed base for NO reason (what they had was working fine) and cause literally millions of dollars of damage (lost productivity as people, some of whom have no access to any IT, simply cannot see their screens anymore). 4) Maybe your installer is not doing what you think it will do. i.e. vulnerability or error in installer. When you mess remotely on a user's PC, this is not to be taken lightly. At all. This is actually squarely the territory we're in with this article. So, I find it kind of funny that in an article on an update vulnerability, someone quips that not only that, but it should be WAY more automatic! :)
whichdan 14y ago
Well, I certainly agree that atleast prompting to update is worthwhile, but there are several steps afterwards -- the equivalent of installing a new application -- every time an update comes out.
- conor23 14y ago
  But that is - MUST be - what you're actually doing: the equivalent of installing a new application. That is the only sane way to do it. Think of how many errors Windows' aggressive updating causes. And that is from Microsoft. They have ONE JOB! (okay, the OS division has one job). So if they do all this internal testing and still push things onto your OS that cause problems. What is a third party to do? The sane thing to do is NOT to treat is as a back door that you can push stuff over, even if the customer asks. The sane thing to do is to treat it like installing a new application. If the 'new' application has problems, then you stop making it available. You're in control. The customer is in control. It's their pc. It doesn't get broken. Really, for anything that interacts with the hardware and OS on as low a level as a display driver, there is really no alternative to massive testing beforehand. Once it's in the wild, you should not expect or have the functionality to simply push firmware or software updates. It should take work and commitment from the customer, the same as installing an application. In the case of firmware, perhaps a bit more.

by conor23 14y ago

deleted 14y ago

[deleted]

conor23 14y ago
Maybe so, but there are a handful of overriding reasons I can think offhand for why you don't make updating more automatic 1) The customer didn't ask. It's their PC, not yours. 2) "Backwards compatibility." See: https://xkcd.com/1172/ https://xkcd.com/1172/ Basically, if you don't leave your program bit-for-bit the same as it was, maybe you break someone's shitty workflow that you could not possibly have predicted and which has no grounding in anything sane. 3) BIG ONE!!! You might have made a mistake. The old version worked fine, for millions of your customers. But you just pushed a version that causes a fairly common setup to have all sorts of problems. How do you protect against this? Well, for one thing, you can make the update process a bit more involved. Track it better. Keep logs. Nip it in the bud. (Meaning when the first few complaints from early adopters - who jump through the hurdles - trickle in. Not millions at once.) That way you won't accidentally screw your whole entire installed base for NO reason (what they had was working fine) and cause literally millions of dollars of damage (lost productivity as people, some of whom have no access to any IT, simply cannot see their screens anymore). 4) Maybe your installer is not doing what you think it will do. i.e. vulnerability or error in installer. When you mess remotely on a user's PC, this is not to be taken lightly. At all. This is actually squarely the territory we're in with this article. So, I find it kind of funny that in an article on an update vulnerability, someone quips that not only that, but it should be WAY more automatic! :)

whichdan 14y ago

Well, I certainly agree that atleast prompting to update is worthwhile, but there are several steps afterwards -- the equivalent of installing a new application -- every time an update comes out.

conor23 14y ago
But that is - MUST be - what you're actually doing: the equivalent of installing a new application. That is the only sane way to do it. Think of how many errors Windows' aggressive updating causes. And that is from Microsoft. They have ONE JOB! (okay, the OS division has one job). So if they do all this internal testing and still push things onto your OS that cause problems. What is a third party to do? The sane thing to do is NOT to treat is as a back door that you can push stuff over, even if the customer asks. The sane thing to do is to treat it like installing a new application. If the 'new' application has problems, then you stop making it available. You're in control. The customer is in control. It's their pc. It doesn't get broken. Really, for anything that interacts with the hardware and OS on as low a level as a display driver, there is really no alternative to massive testing beforehand. Once it's in the wild, you should not expect or have the functionality to simply push firmware or software updates. It should take work and commitment from the customer, the same as installing an application. In the case of firmware, perhaps a bit more.