On 14/10/14 20:57, Jim Gettys wrote: > On Tue, Oct 7, 2014 at 2:38 PM, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> > wrote: > >> On Tue, Oct 7, 2014 at 2:11 PM, James Woodyatt <jhw@xxxxxxxxxxxx> wrote: >>> On Fri, Oct 3, 2014 at 11:39 AM, Phillip Hallam-Baker >>> <phill@xxxxxxxxxxxxxxx> wrote: >>>> >>>> Yes, I agree with the replies so far, more or less. [...] >>> >>> >>> As general principle, my preference is for networked home devices to >>> *request* access to its maker's online service, with the owner having the >>> option to decline and to still have a functional device with the basic >>> features all working as a normal person would naturally expect. When I >>> think about arguments for *demanding* access to Internet service, I can >>> think of precisely one for which I am forced to admit there are >> personally >>> convincing reasons for doing it: emergency firmware update. Even there, >> I >>> still squirm, and I can sympathize with people who disagree. >>> >>> Really, if my personal preferences are to rule the day, then everything >> else >>> ought to be in the category of "you bought a $DEVICE, and it does >> $FUNCTION >>> just fine, but if you let it call it's mother periodically, then it will >>> also do $OPTION as well, and won't that be nice. Okay? [y/N]" (FWIW, I'm >>> reasonably sure my current employers hold a compatible view on this >> topic, >>> but— you know— I can't speak for them, of course.) Enabling more local >>> autonomy would make me happier, and my hunch is that this may actually >> be a >>> minority view in the Internet engineering community, but I'm happy to >>> represent yo. For reals. >> >> I think the starting point would be for the device to tell my system >> what it is and what version of firmware it is running. >> >> Automatic firmware updates have already become a source of nuisance >> rather than sanity in the house. When I turn something on I want it to >> work NOW! NOW! NOW! About one time in ten a given device will turn on >> and then start downloading stuff for ten minutes. >> >> What really irritates is the approach typified by my DVR set top box >> which is on 24/7 and connected to the net. When an update notification >> is sent it posts a note on the splash screen then waits for someone to >> attempt to use it. At that point and only at that point does it begin >> the mandatory update. There is no option to cancel, the machine just >> waits until it can inconvenience someone. >> >> >> Right now I have a house with three Internet thermostats and six smoke >> alarms, all of which have temperature sensors and occupancy sensors. >> It would seem like a no brainer to connect these up in an intelligent >> way so that lights get switched off when there is nobody in a room and >> using the temperature in the rooms that are occupied to set the >> furnace temperature rather than the ones that are not. >> >> > ​There is a serious issue lurking here: it is *not* safe for devices to be > without software updates. And it isn't safe to presume the upstream > manufacturer is being diligent in providing those updates. And nagging end > users to do something that they don't understand is also not a solution. > > Those of you unaware of the "Honeymoon effect" should read the following > paper: > > http://www.acsac.org/2010/openconf/modules/request.php?module=oc_program&action=view.php&a&id=69&type=2 > > Both heartbleed and shellshock are good examples of this phenomena > (thankfully, shellshock does not happen to be present in most of these > devices, but in systems which are upgraded on an ongoing basis. > > Worse yet are the "hidden monocultures" we have: binary blobs throughout > our systems that may make update impossible (on the scale of the lifetime > of these devices). > > See: > http://gettys.wordpress.com/2014/10/06/bufferbloat-and-other-challenges/ > > The other challenges (security) dwarf bufferbloat. > > I believe we need to rethink how we build software for these devices, in a > pretty fundamental way. If someone wanted to write an I-D describing a useful thing the IETF could do in this space, I'd be very happy to see that and to try move it along however is best done. (When I say "this space" I mean at least s/w update for devices like sensors of various kinds and DSL-modem like things.) I think its possible, but not a slam-dunk, that there is good work that the IETF could do on that topic. S. > > - Jim > > > ​ >