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

Hi, Tobie-san,
Thank you for showing your opinion.

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

I think so.

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

Yes!


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

We may imagine systems such as GITHUB for hardware blue print. In that case, the concept of the "fork" is 
interesting if there are open-source.

And, my original idea for such a trade-off matter is like following.
A board computer that a Web browser is implemented will constitute a machine (hardware) with sensors, actuators, 
frames, joints and a housing. In DIY and Maker Movoment, it will be recommended that anyone make and modify such a 
hardware freely. It may be included in hardware kit such as the customizable robots including the board computer 
which you mentioned.

In the idea that a browser has a URL, when such a hardware is made by kit and DIY, it is assumed that DIYer can set 
the URL freely. For example, the URL may be setable in the preference setting window of the browser.

On the other hand, such a URL will be fixed by a provider (maker) when a provider of the finished hardware wants to 
manage the software for it firmly. The software of 3rd party may be admitted individually by CORS.

Either will be chosen by the circumstances of a provider and the producer of the hardware.


> 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.
> We're not there yet, but that certainly will be a great improvement when
> it lands.
> Agree 100%. I think to enable that, the best strategy is to figure out
> precisely what risks we are trying to mitigate.

I think so.

> 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?
> 
In addition, we assume the following limitations peculiar to Low Level I/F.
The software cannot detect which address of which port sensors and actuators are connected to automatically.
The software cannot detect what kind of function a connected sensor or actuator have automatically.
Therefore, it is necessary for those information to be set to every individual hardware with manually.

Furthermore, in the machine (hardware) having actuators (such as servo-motor, solenoid etc.), we assume the 
following issues.
The actuators influence each other through joints and frames of the hardware. And the independent operation of each 
actuator is usually impossible. Therefore, it seems to be necessary to consider the whole hardware to be a 
complicated actuator. As a result, actuators become very various, and the abstraction may be difficult.

Regards,

Satoru

Received on Wednesday, 25 November 2015 08:56:29 UTC