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

Hi,
Thank you for your comment.

I have used the "machine" word, without performing sufficient definition. A machine here is the entire hardware by which SBC (single board computer) with web runtime, motors, and sensors were embedded into it. For example, it may be a lawn mower hardware which runs by itself with a touch display.

DIYer and Maker will create such a thing freely. Namely, it is in the situation where the various machines with which web runtime was embedded are produced freely steadily. A movement which encourages it is like usecase about it.

In that situation, each machine has a different characteristic, respectively. For example, they are the difference in the kind of the sensor and motor which are connected to the interface of SBC, the difference in the movable range of a motor, etc.

Here, basically individual Web App becomes the software only for controlling such individual hardware.

Therefore, the mechanism for identifying an individual machine will be required for such web apps. For that purpose on Web, URL may be suitable.

Where, all the machines based on the same blueprint, i.e., the same model, may have the same URL.

Regards,

Satoru

> > 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 23:50:12 UTC