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

On Thu, 12 Nov 2015 11:53:42 +0900
Satoru Takagi <sa-takagi@kddi.com> wrote:

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

What are "machines" in this context?
SBCs such as CHIRIMEN, or peripherals connected to I2C/GPIO?

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

It's because Web I2C/GPIO APIs don't need to prevent this.
If machines were broken, it's developper's fault.
I don't know what you worry about.
Could you elaborate?

> This is an issue in spreading such APIs as WebI2C and WebGPIO broadly.

I don't think it's an issue.
What do you want to develop the APIs for?
It sounds like that you want to develop generic APIs for peripherals connected to I2C/GPIO.
I think Web I2C/GPIO APIs should be agnostic on what peripheral is connected.

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

We should think about who use the APIs.
The APIs are supposed to be used for dedicated devices in the first place.
Do you want to accept third parties' installation?

Cheers,
Futomi


> 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

--
Newphoria Corporation
Chief Technology Officer
Futomi Hatano
--
futomi.hatano@newphoria.co.jp
http://www.newphoria.co.jp/

Received on Thursday, 12 November 2015 09:20:46 UTC