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:
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).
The other challenges (security) dwarf bufferbloat.
I believe we need to rethink how we build software for these devices, in a pretty fundamental way.
- Jim