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

Hi Tobie-san,

I am sorry that I did not reply sooner to you. And congratulations!

About 1), By the setting mistake of URL, etc., I also think that there is
an issue that an accident damage may be caused.
About 2), Under the environment where the freedom of installation of a
browser is ensured, it will be as your indication.
And you point out further, I also think it hard to match the spirit of Web
to investigate such a purpose itself.

Besides, MozOpenHard which is another community in which I have
participated is pursuing only construction of the Web Runtime environment
which promotes creation of the machine for DIYer. Accordingly, I prefer
investigating only 1) as a scope personally.

Since I think that you provide the very important opinion, I am feeling
that it is too good to be discussed by only this small Browser Robotics CG.
I would like to share this discussion with ML of a MozOpenHard community.

Regards,

Satoru

> Hi Satoru-San,
> 
> Sorry for not getting back to you earlier, my third child was born on
> the day following your last email and that has kept me pretty busy
> since. :)
> 
> On Wed, Nov 25, 2015, at 09:55, Satoru Takagi wrote: 
> > 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.
> 
> Thanks for the clarification. I'm still bothered by the following:
> 
> 1) the URL now serves both as an identifier for the device AND
> permissioning/access. In this scenario I sort of loose the idea that I
> could learn more about a particular hardware setup (and perhaps even
> automatically get a JS library to control it) thanks to that URL,
> effectively loosing the benefit of protecting the hardware from
> accidental damage due to improper manipulation.
> 2) once the URL is fixed by a provider, you're effectively asking the
> user agent to enforce some form of policy on behalf of the provider even
> possibly against the user's will. This seems both unenforceable (it's
> easy to build a browser that will make the URL settable despite the
> provider's intention) and contrary to the spirit of the Web (remember
> the uproar around EME).
> 
> I feel like precisely listing the problems which this solution attempts
> to solve along with those that are specifically out of scope would
> really help (me).
> 
> That said, I'm impressed by the depth of your reflexion on this topic so
> far!
> 
> Best,
> 
> --tobie
> 
> 
> 
> 
> 

----------------------------------------------
           みんながみんな英雄。
　   http://www.au.kddi.com/pr/3taro/
----------------------------------------------
Satoru Takagi (高木　悟)

W3C AC Representative, SVG2 Editor

KDDI CORPORATION, R&D Strategy Department,
Technology Development Division
Email:sa-takagi@kddi.com

この電子メール及び添付書類は名宛人のための秘密情報を含んで
います。名宛人以外の方が受信された場合は、お手数をお掛けい
たしますが、破棄をお願いいたします。

Received on Thursday, 21 January 2016 09:03:21 UTC