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

Hi, all,

On W3C TPAC2015, we had various opinions for MozOpenHard project.
There was particularly much indication of the following cares.

We want to 
-create a variety of machines freely, 
-put Web browser-based runtime on them, and 
-control them by application software to work on that runtime.
At this point, if we create two entirely different machines, we must prepare different application software for each
 one.
Each of the application software will set entirely different commands to I2C or GPIO API to control actuators or 
sensors attached to each machine.
If we run the application for the other machine by mistake, it may be broken.
Current Web I2C/GPIO specifications and CHIRIMEN implementations do not have mechanism to prevent this.
This is an issue in spreading such APIs as WebI2C and WebGPIO broadly.


In CHIRIMEN (our prototype), we currently implement APIs to work only in Certified Application.
Therefore, they can work only in case of preinstallation or installation by developers themselves.
This issue is currently not exposed because CHIRIMEN is a computer for prototyping by developers. 
However, it may be exposed when third parties' installation begins.
Therefore, we explore the solution for the issue.


The simple solution may be the following:
- An API grasping the characteristic of the peripherals connected to I2C or GPIO interface is prepared, and
- GPIO and the I2C bus are operated according to information obtained from API.
This is the method often used in USB or Bluetooth.

However, it will not be effective for the connected peripherals.
In such low-level interfaces, the function to get the characteristic of the connected peripherals does not exist.
Furthermore, a machine created by the combination of those peripherals gives additional characteristic and 
limitation to each peripheral.

For example, please imagine working machine was created by a servo motor.
Originally, each servo motor may have a movable range of 120 degrees.
However, with the machine which it was installed in, a movable range of 60 degrees may be permitted.
We cannot avoid the destruction of the machine only by the characteristic which is provided by a servo motor.


Therefore we imagine the other method as follows:

It is an execution limitation function of API similar to same origin policy combining an identifier with a meaning 
such as window.navigator.userAgent.

*The developers make the identifier by the URL corresponding to each machine which they have created. The URL may 
have Web of the explanation about the machine. But it is only a URL that is necessary in this mechanism.

*The developers set the URL to window.navigator.userAgent-like readonly attribute of the web runtime embedded in 
that machine. This setting should be set as runtime environment.

*Low level APIs such as webIGPIO or webI2C shall work only in application software to belong to a domain same as 
that URL attribute, unless special setting such as CORS is accomplished.

What do you think this method?

Regards,

Satoru

Received on Thursday, 12 November 2015 02:54:38 UTC