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!).

Pisser is that I need a mechanism that will be supportable
for 20-30 years. This likely rules out many commodity
approachs (will we be using NANO-SD cards? PICO-SD cards?
will USB A/B have given way to C? Or D/E/F?)

If you assume updates are few and far between, the cost
of the transport medium has little impact on TCO (unlike
on-line updates which have a big impact on TCO!).

And, if you further assume that the time to perform an
update is immaterial (because they are infrequent and
because the system allows updates to happen WHILE it is
in use -- unlike "reboot to complete your update"),
then you don't need a fast interface to deliver the new
content.

So, it seems that a reasonable approach could be a "module"
that talks to the product using an existing communications
medium inherent in the product's design (in my case, wired
or wireless ethernet). The design of the "update device"
can then change with each update -- so long as the system
interface remains constant.

A dog slow "processor" that can push packets from some
storage medium out to the system interface offers lots
of design opportunities for processing (dedicated logic)
and storage (media devices).

Because it is active, it can also make note of how and
when it was "consumed" (should reuse want to be discouraged)

As it's only a one-time use device, there's no need to make it
serviceable -- discard when done. (no desire to have it
returned for reuse as it's cost would be a handful of dollars;
likely less than the price of a first class *stamp*, soon)

Any problems with this approach? Export controls may be an
issue but I can leave that to someone else to sort out;
maybe just ignore those markets? (I've had to work in markets
where you had to smuggle EPROMs through customs...)

On 25-Nov-23 10:09 am, 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!).
>
> Pisser is that I need a mechanism that will be supportable
> for 20-30 years.  This likely rules out many commodity
> approachs (will we be using NANO-SD cards?  PICO-SD cards?
> will USB A/B have given way to C?  Or D/E/F?)
>
> If you assume updates are few and far between, the cost
> of the transport medium has little impact on TCO (unlike
> on-line updates which have a big impact on TCO!).
>
> And, if you further assume that the time to perform an
> update is immaterial (because they are infrequent and
> because the system allows updates to happen WHILE it is
> in use -- unlike "reboot to complete your update"),
> then you don't need a fast interface to deliver the new
> content.
>
> So, it seems that a reasonable approach could be a "module"
> that talks to the product using an existing communications
> medium inherent in the product's design (in my case, wired
> or wireless ethernet).  The design of the "update device"
> can then change with each update -- so long as the system
> interface remains constant.
>
> A dog slow "processor" that can push packets from some
> storage medium out to the system interface offers lots
> of design opportunities for processing (dedicated logic)
> and storage (media devices).
>
> Because it is active, it can also make note of how and
> when it was "consumed" (should reuse want to be discouraged)
>
> As it's only a one-time use device, there's no need to make it
> serviceable -- discard when done.  (no desire to have it
> returned for reuse as it's cost would be a handful of dollars;
> likely less than the price of a first class *stamp*, soon)
>
> Any problems with this approach?  Export controls may be an
> issue but I can leave that to someone else to sort out;
> maybe just ignore those markets?  (I've had to work in markets
> where you had to smuggle EPROMs through customs...)
>

I wouldn't want to rely on wireless ethernet - there's too much in there
that could change over time to the extent that no then available device
could talk to it.

Preventing managers from causing on-line update to become available is
really difficult as long as software can do updating, since even if
on-line update is not implemented from day one, it could be implemented
via the last non-online update.

The solution is a device that is physically incapable of updating itself
unless some local action is taken, such as pressing a button. As long as
no one implements a remote button-pressing device.

Sylvia.

On 11/24/2023 5:05 PM, Sylvia Else wrote:
> On 25-Nov-23 10:09 am, 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!).
>>
>> Pisser is that I need a mechanism that will be supportable
>> for 20-30 years.  This likely rules out many commodity
>> approachs (will we be using NANO-SD cards?  PICO-SD cards?
>> will USB A/B have given way to C?  Or D/E/F?)
>>
>> If you assume updates are few and far between, the cost
>> of the transport medium has little impact on TCO (unlike
>> on-line updates which have a big impact on TCO!).
>>
>> And, if you further assume that the time to perform an
>> update is immaterial (because they are infrequent and
>> because the system allows updates to happen WHILE it is
>> in use -- unlike "reboot to complete your update"),
>> then you don't need a fast interface to deliver the new
>> content.
>>
>> So, it seems that a reasonable approach could be a "module"
>> that talks to the product using an existing communications
>> medium inherent in the product's design (in my case, wired
>> or wireless ethernet).  The design of the "update device"
>> can then change with each update -- so long as the system
>> interface remains constant.
>>
>> A dog slow "processor" that can push packets from some
>> storage medium out to the system interface offers lots
>> of design opportunities for processing (dedicated logic)
>> and storage (media devices).
>>
>> Because it is active, it can also make note of how and
>> when it was "consumed" (should reuse want to be discouraged)
>>
>> As it's only a one-time use device, there's no need to make it
>> serviceable -- discard when done.  (no desire to have it
>> returned for reuse as it's cost would be a handful of dollars;
>> likely less than the price of a first class *stamp*, soon)
>>
>> Any problems with this approach?  Export controls may be an
>> issue but I can leave that to someone else to sort out;
>> maybe just ignore those markets?  (I've had to work in markets
>> where you had to smuggle EPROMs through customs...)
>
> I wouldn't want to rely on wireless ethernet - there's too much in there that
> could change over time to the extent that no then available device could talk
> to it.

I (currently) only use wired connections. This for several reasons:
- requires physical access for tampering/interception/DoS
- allows power to be distributed remotely
- high bandwidth regardless of scale

But, I can't rule out someone, eventually, opting for a wireless connection
(with caveats) within the system -- for some special need.

> Preventing managers from causing on-line update to become available is really
> difficult as long as software can do updating, since even if on-line update is
> not implemented from day one, it could be implemented via the last non-online
> update.

The bar is set pretty high, for that. I don't use a TCP/IP stack
so anyone wanting to talk to the outside world would have to undertake
the task of integrating that functionality and associated "capabilities"
(permissions) as well as determining who/what would use them.

(The hardware to do so is a relatively trivial undertaking)

Additionally, developing (and validating) a mechanism to protect the rest
of the system from any potential hostile actions that the new attack
surface makes possible.

And, of course, committing to supporting an update server (and policy)
at a well-known address for a substantial period of time.

If you "run the numbers", it's cheaper to make a semi-disposable
device to do this (that gives you the ability to keep revising
subsequent devices as different storage media come into fashion)

> The solution is a device that is physically incapable of updating itself unless
> some local action is taken, such as pressing a button. As long as no one
> implements a remote button-pressing device.

New devices ("nodes") are introduced to my system by exactly such a
mechanism. The admission terminal is intended to be located someplace
physically secure (so the initial communications with the device can
be secure and so only trusted personnel can perform said actions).

The device's identity and capabilities are discovered through this
admission process, followed by KEX and the registration of the device
in the system's configuration.

Thereafter, the ultimate network location of the device is discovered
when it finds it's ultimate home.

I was thinking of using the same mechanism, protocol, etc. for an
"updater" device -- whose function is to deliver new software to the
system. As this is of a transitory nature, the device need never
"appear" anywhere other than the admission terminal and, there, only
for the time it takes to dump its contents.

On 25-Nov-23 4:30 pm, a a wrote:
> The arsehole Don Y <blockedofcourse@foo.invalid> persisting in being an Off-topic troll...
>

That seems rather harsh.

The line between hardware and software has become rather blurred, with
many devices that Joe public would think of as just electronics actually
containing some software elements.

Sylvia.

On 11/25/2023 12:34 AM, Sylvia Else wrote:
> On 25-Nov-23 4:30 pm, a a wrote:

I'm surprised ANYONE still sees posts from "a a"!

> That seems rather harsh.
>
> The line between hardware and software has become rather blurred, with many
> devices that Joe public would think of as just electronics actually containing
> some software elements.

I suspect there are far more "deeply embedded" devices in existence,
today, than "pure electronic" devices -- both in numbers and designs.
It seems far too easy to put a processor into a design rather than
a few discretes (and then let feeping creaturism do the rest!)

In fact, the question centered around a physical DEVICE to deliver
updates -- instead of the ubiquitous "software service" that is
used, nowadays. (I actually suggested it could be "dedicated logic")

[I guess it takes a certain level of intelligence to be able to
perceive that (likely "a a" doesn't rise to that level). But,
that's what you'd expect from folks who live under bridges...]

On Friday, November 24, 2023 at 3:09:47 PM UTC-8, 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!).
>
> Pisser is that I need a mechanism that will be supportable
> for 20-30 years. This likely rules out many commodity
> approachs (will we be using NANO-SD cards? PICO-SD cards?
> will USB A/B have given way to C? Or D/E/F?)

Futureproofing is an unsolved problem. Backstop for
such issues, is swapping major parts of the device
back to the factory.

This assumes the factory with the update is not in a war zone
or supervolcano caldera.

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.
(other cheap fast serial protocols are available)

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.

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 :(

It still works fine for ROW programme content.

--
Martin Brown

Martin Brown <'''newspam'''@nonad.co.uk> 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.
> (other cheap fast serial protocols are available)
>
> 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.
>
> 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 :(
>
> It still works fine for ROW programme content.
>
Gee, Martin, what part of “move fast and break things“ didn’t you get? ;)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC /
Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics

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?