Re: Programmatic and security models for IoT

No. The worst that can happen is that the (potentially many) different loci of computing get into an inconsistent state and break something in the real world. (some trivial examples: one missing temperature input skews the heating/cooling control; or a burglar alarm waits too long for a connection to become re-established, letting in the thieves - or doesn’t wait long enough and the neighbours get upset with false alarms).

Different composed devices need to take account of the desired CAP characteristics (as in Brewer’s Theorem) of the specific behaviour that’s supposed to emerge from the composition, while not requiring (too much) coupling between components.

In the worst examples that I’ve seen the Things’ behaviours can be inconsistent.

From an Object Capability point of view, specific handing off of authority means that there’s no requirement for an always available authorisation service.

tc
> On 6 Feb 2015, at 16:18, Valerio Bellizzomi <[email protected]> wrote:
> 
> On Fri, 2015-02-06 at 15:21 +0000, Tim Coote wrote:
>>> On 6 Feb 2015, at 14:50, Valerio Bellizzomi <[email protected]> wrote:
>>> 
>>> On Thu, 2015-02-05 at 12:10 +0000, Tim Coote wrote:
>>>> I’m also tracking js, but I’m not a huge fan of such poor typing - Flow seems to be an approach to addressing this.
>>>> I like your anecdotes of adopting the technologies.
>>>> 
>>>> Thanks for those links. Like many that I’ve seen, there seems to be an emphasis on ‘happy path’ coding. IoT is a really hostile compute environment:
>>>> - connections are very flakey
>>> 
>>> 
>>> where connections are flaky I would expect something like DTN.
>>> http://en.wikipedia.org/wiki/Delay-tolerant_networking
>>> 
>>> 
>> Actually, the flaky comms was something that I considered well addressed by E’s distributed computing model (http://www.skyhunter.com/marcs/ewalnut.html#SEC18), which, to my mind, puts about the right amount of awareness of the potential failures into the mind of the developer (ie she has to consider failure of any remote access), while not exposing the very difficult challenges of unknown failures (eg the work of Waterken and COVR assure less fragile systems.)
> 
> well the worst that can happen is that the connection is absent and you
> have to collect data for later transmission. this has been addressed in
> dtn too.
> 
> 
>> Tim
>> _______________________________________________
>> cap-talk mailing list
>> [email protected]
>> http://www.eros-os.org/mailman/listinfo/cap-talk
> 
> 
> 
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk

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