Re: Consideration about prevention of Low Level I/F APIs being executed by mistake

Satoru-San,

Please find my comments inline.

On Fri, Nov 20, 2015, at 01:08, Satoru Takagi wrote: 
> >So this ties a particular hardware setup to a unique origin?
> Yes!
> 
> Surely it becomes a centralized mechanism, when hardwares (what I called
> it
> the machine to) based on the same blueprint are mass-produced and many
> people use it.

>From the use-cases you showed me in Sapporo (cameras, printers, washing
machines, etc. with integrated screens, it appears that the common case
is for tight software/hardware coupling combined with some sort of kiosk
mode.

No one is going to browse the Web on a printer.

However, it might be interesting to allow third parties to build apps on
top of existing hardware. For instance, consider a scanner for which a
third party would build an application which would let you upload your
scans directly to the cloud (e.g. using Dropbox's API).

There are obvious huge security and privacy risks here, but also pretty
exciting innovation capabilities.

Such a system would require third party to access the hardware and
understand its characteristics, or maybe the hardware maker to provide
higher level abstractions for the particular hardware configuration in
the form of JavaScript libraries (or some form of cross-origin
messaging).

> On the other hand, on the case where create one-off hardware by oneself
> and
> use it oneself (DIY), it will not be in a centralized situation. Because
> it
> is only one personal individual machine. Probably, on Maker Movement, it
> will be nice that such a case is also respected. It is in the situation
> where everyone makes different hardwares freely so that everyone make
> WebApps freely.

Yes, on an individual level, this proposal doesn't seem to be an issue.
However, one of the key parts of the Maker Movement is the ability to
share, so it seems that this should also be taken in account in the
design of a solution.

For example, one could imagine a company releasing a hardware kit which
could be used in a variety of way. Multiple developers could then build
tutorials for this kit which would combine instructions on how to
assemble the hardware for that specific use case and runnable inline
examples. It would be against the spirit of the Web and of the Maker
Movement if these developers were to seek permission from the hardware
manufacturer to grant them access to the hardware. Also, it would place
a legal burden on the hardware manufacturer since it would have
implicitly vetted this third party. Thus the hardware manufacturer would
want to guarantee that the hardware was used according to spec and
therefore would want means to control the third party code, leading to
review processes, code signing, etc. Not of which would provide the
desired outcome.


> It seems that the present Web has implicit stereotypes on the hardware in
> which the browser was implemented. It is PC, smart phone, and tablet.

Yes, this is true, though it has been changing a lot recently. Less than
a decade a go, the Web was strictly desktop. This can and will change
more thanks to efforts like this.

> And some stereotypes which can be enumerated are assumed also on peripherals
> added to such hardwares via Bluetooth or USB.

We're not there yet, but that certainly will be a great improvement when
it lands.

> Meanwhile, free creation of
> the hardware using low level I/F, such as I2C and GPIO, may require the
> freedom of the breakaway from such stereotypes. Probably, this is another
> viewpoint of openness. I would like to search for the good mechanism of providing any case with
> each openness.

Agree 100%. I think to enable that, the best strategy is to figure out
precisely what risks we are trying to mitigate.

My understanding is we have at least the following:

1. regular security and privacy risks of providing access to sensors to
third parties.
2. enhanced risk of providing access to actuators to third party
(imagine the extreme example of medical equipment or some such).
3. risk of third party damaging the hardware either
    a) unintentionally or
    b) maliciously.

Am I missing anything?

--tobie

Received on Friday, 20 November 2015 10:02:50 UTC