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

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

Received on Wednesday, 6 January 2016 16:30:19 UTC