Re: Access control for IoT

--===============7841076488252841784==
Content-Type: multipart/alternative; boundary=047d7bdc15eaa0210a0529a5d020

--047d7bdc15eaa0210a0529a5d020
Content-Type: text/plain; charset=UTF-8

On Mon, Jan 18, 2016 at 5:11 PM, Ben Kloosterman <[email protected]> wrote:

> Not practical / wise for HW / small  ioc .  Yet to see a single mother
> board auto update - with good reason . HW normally works on no changes  and
> if there are any changes there is normally a very length cycle before its
> released. This includes Flash /EEproms  , not to mention that it some cases
> you can brick the device with some Eeproms if you do  it to often.
>

Not true. It is quite common for embedded hardware these days to not only
be field updatable, but be able to transparently and incrementally download
updates and install them. I will again point to my employer as reference.
We do it, so I'm afraid I have to ignore your claims to the contrary.

Likewise, I would argue it's irresponsible to put devices which don't
automatically update onto the Internet (that is the subject of this
discussion, right? The *Internet* of Things).

There are certainly many applications of hardware for which updates are a
bad idea, or devices which are too small or constrained to support
automatic updates. But you have to Venn Diagram that with the types of
devices it's reasonably responsible to connect to the Internet and assign
an IP address to.

I would argue it's irresponsible to put any device on the Internet which is
not capable of receiving software updates.

-- 
Tony Arcieri

--047d7bdc15eaa0210a0529a5d020
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jan 18, 2016 at 5:11 PM, Ben Kloosterman <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><span><div>Not practical / wise for HW / sma=
ll =C2=A0ioc .=C2=A0 Yet to see a single mother board auto update - with go=
od reason . HW normally works on no changes =C2=A0and if there are any chan=
ges there is normally a very length cycle before its released. This include=
s Flash /EEproms =C2=A0, not to mention that it some cases you can brick th=
e device with some Eeproms if you do =C2=A0it to often.=C2=A0</div></span><=
/div></div></div></blockquote><div><br></div><div>Not true. It is quite com=
mon for embedded hardware these days to not only be field updatable, but be=
 able to transparently and incrementally download updates and install them.=
 I will again point to my employer as reference. We do it, so I&#39;m afrai=
d I have to ignore your claims to the contrary.<br></div><div><br></div><di=
v>Likewise, I would argue it&#39;s irresponsible to put devices which don&#=
39;t automatically update onto the Internet (that is the subject of this di=
scussion, right? The *Internet* of Things).</div><div><br></div><div>There =
are certainly many applications of hardware for which updates are a bad ide=
a, or devices which are too small or constrained to support automatic updat=
es. But you have to Venn Diagram that with the types of devices it&#39;s re=
asonably responsible to connect to the Internet and assign an IP address to=
.</div><div><br></div><div>I would argue it&#39;s irresponsible to put any =
device on the Internet which is not capable of receiving software updates.<=
/div><div><br></div></div>-- <br><div>Tony Arcieri<br></div>
</div></div>

--047d7bdc15eaa0210a0529a5d020--

--===============7841076488252841784==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk

--===============7841076488252841784==--