Long term software update mechanism

On 11/26/2023 3:50 AM, Martin Brown wrote:
> On 24/11/2023 23:09, Don Y wrote:
>> I need a mechanism to allow for software updates to be
>> installed.  The (abused) "on-line" approach is unacceptable
>> (it forces the device to be "exposed" and makes updates
>> too easy (which seems to mean too frequent!).
> 
> An Ethernet socket and a dedicated line to connect it to whatever hardware du 
> jour happens to be?
> I can't see physical wired Ethernet going away any time soon.

Yes, I predicated my entire design on it being available as a
communications technology (between nodes).  So, why not ALSO
rely on it as the medium over which to deliver updates from
an "updater node" (that only interacts with the system for the
duration of the update delivery)?

> (other cheap fast serial protocols are available)

Ethernet gives me the distance, bandwidth and power delivery
capability the system's nodes need.  If I use some OTHER
medium for the updates' delivery, then I add another
technological dependency.

> I still have the odd thing hanging around that requires it's firmware to be 
> bitbashed down a bidirectional parallel printer port (remember them?). I keep 
> one such machine with that, RS485, an ancient SCSI card and even more antique 
> IEEE488 card for just such occasions.

I have a parallel port based 10Base2 adapter.  I use it with
a Compaq Portable 386 (surprisingly, it gets almost 100KB/s)
as the portable has only two (expansion) ISA slots (which I
have already made use of).

> The one that really annoys me is my high end internet radio tuner (early 
> adopter) the BBC has effectively bricked it since they changed their streaming 
> format and the device now more than 5 years old is no longer supported. It is a 
> *BIG* problem with so-called "smart" devices :(

Yes.  One of my design constraints was NOT to require the
continued availability of any outside service in order for the
system to remain operational.

Sadly, most smart devices have gone the other route, arguing that
they "need" to do so in order to handle the DDNS issue.

"Really?  I need for you to be involved so I can talk to my
stove from afar?  Even if I'm in the NEXT ROOM???"

I'm giggly with anticipation of some {nation,world}-wide
hack on one of these services that remotely crashes (or
activates!) every such appliance and the public outrage
that comes with it...

> It still works fine for ROW programme content.

On Sunday 26 November 2023 at 17:56:04 UTC, Don Y wrote:
> On 11/26/2023 3:50 AM, Martin Brown wrote: 
> > On 24/11/2023 23:09, Don Y wrote: 
> >> I need a mechanism to allow for software updates to be 
> >> installed.  The (abused) "on-line" approach is unacceptable 
> >> (it forces the device to be "exposed" and makes updates 
> >> too easy (which seems to mean too frequent!). 
> > 
> > An Ethernet socket and a dedicated line to connect it to whatever hardware du 
> > jour happens to be? 
> > I can't see physical wired Ethernet going away any time soon.
> Yes, I predicated my entire design on it being available as a 
> communications technology (between nodes). So, why not ALSO 
> rely on it as the medium over which to deliver updates from 
> an "updater node" (that only interacts with the system for the 
> duration of the update delivery)?
> > (other cheap fast serial protocols are available)
> Ethernet gives me the distance, bandwidth and power delivery 
> capability the system's nodes need. If I use some OTHER 
> medium for the updates' delivery, then I add another 
> technological dependency.
> > I still have the odd thing hanging around that requires it's firmware to be 
> > bitbashed down a bidirectional parallel printer port (remember them?). I keep 
> > one such machine with that, RS485, an ancient SCSI card and even more antique 
> > IEEE488 card for just such occasions.
> I have a parallel port based 10Base2 adapter. I use it with 
> a Compaq Portable 386 (surprisingly, it gets almost 100KB/s) 
> as the portable has only two (expansion) ISA slots (which I 
> have already made use of).
> > The one that really annoys me is my high end internet radio tuner (early 
> > adopter) the BBC has effectively bricked it since they changed their streaming 
> > format and the device now more than 5 years old is no longer supported. It is a 
> > *BIG* problem with so-called "smart" devices :(
> Yes. One of my design constraints was NOT to require the 
> continued availability of any outside service in order for the 
> system to remain operational. 
> 
> Sadly, most smart devices have gone the other route, arguing that 
> they "need" to do so in order to handle the DDNS issue. 
> 
> "Really? I need for you to be involved so I can talk to my 
> stove from afar? Even if I'm in the NEXT ROOM???" 
> 
> I'm giggly with anticipation of some {nation,world}-wide 
> hack on one of these services that remotely crashes (or 
> activates!) every such appliance and the public outrage 
> that comes with it...
> > It still works fine for ROW programme content.

On 27-Nov-23 4:55 am, Don Y wrote:

> "Really?  I need for you to be involved so I can talk to my
> stove from afar?  Even if I'm in the NEXT ROOM???"

It bothers me that such devices are typically inside one's firewall, and 
that one's security is therefore dependent on whatever security is in 
place at the server side.

I've created a separate LAN for such devices (Smart TV, etc), but that's 
going to beyond the skills of most owners, who are most likely not even 
aware of the issue.

Sylvia.

On 11/26/2023 5:29 PM, Sylvia Else wrote:
> On 27-Nov-23 4:55 am, Don Y wrote:
> 
>> "Really?  I need for you to be involved so I can talk to my
>> stove from afar?  Even if I'm in the NEXT ROOM???"
> 
> It bothers me that such devices are typically inside one's firewall, and that 
> one's security is therefore dependent on whatever security is in place at the 
> server side.

Exactly.  We don't let ANYTHING talk to the outside world
(save for this "disposable" computer used solely for email
and WWW).

> I've created a separate LAN for such devices (Smart TV, etc), but that's going 
> to beyond the skills of most owners, who are most likely not even aware of the 
> issue.

Note that there is nothing that says those devices can't be
semi-malignant and canvas the devices they can reach on
<whatever> subnet you set up.

     "Sylvia also appears to have a Nest thermostat, a Ring
     doorbell, and an LG refrigerator... in addition to *me*!"

Given how little effort towards security is typically invested in the
*initial* design of products (it is most often "an afterthought"),
how can you be sure you aren't putting your customer at risk?