Re: [Spud] OS updates on embedded devices

[Brian Trammell <[e-mail]>]

What I take away from this tangent: avoiding certain types of badness is probably a necessary function of any minimal common transport such as SPUD. Which types of badness those are is a point for detailed discussion, but it probably includes avoiding anything that looks like reflection or amplification, and anything that looks like trivial state exhaustion, which we need to consider very carefully in a protocol designed to make state establishment on path explicit.

Thanks, cheers,

Brian

> On 09 Apr 2015, at 23:38, Tom Herbert <[e-mail]> wrote:
> 
> On Thu, Apr 9, 2015 at 2:09 PM, Phillip Hallam-Baker
> <[e-mail]> wrote:
>> We are quite a way afield here. But there are very good reasons for
>> NOT wanting automatic updates.
>> 
>> Security for me means that the device does what I want it to and
>> nothing else. Having the system change behavior because some code
>> monkey decided to add some Kewl features is a security vulnerability
>> as far as I am concerned.
>> 
>> I have Sonos devices in some of the rooms. They are practically
>> unusable because the idiots who make the app insist on making changes
>> that require the already sluggish iPhone app to be updated regularly.
>> 
>> When I want to turn the radio on I want it to take less than a second.
>> Sonos is already slow. But when it asks for an update of the app,
>> someone has to bring the phone to me and have me enter the password to
>> update it. Then the device will often fail to find the app store. If
>> it does find it then it is another five minutes to load the new app.
>> 
>> 
>> If a network device did the same thing it would undoubtedly break my network.
> 
> This discussion is probably more relevant in the IoT and security
> lists. But anyway, as we start attaching more and more devices to the
> the Internet they eventually become targets. One known problem we face
> is that security vulnerabilities, unlike simple bugs, are usually not
> caught in initial development. It's only after significant deployment
> that would-be attackers get interest in this. So our choices are:
> don't connect devices, update software (wherever it is) on running
> devices, live with security vulnerabilities, buy new HW, have devices
> live behind other devices that provide security, etc. Given that these
> devices are targeted to end users and that some serve life critical
> functions (like you smoke detector), a transparent solution seems
> essential.
> 
> Tom
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud