Re: Bringing APIs for experimental hardware/software to the Web

On Wed, Nov 12, 2014 at 12:36 PM, Dimitri Glazkov <dglazkov@google.com>
wrote:

> Nevertheless, I am optimistic. I would like to have this discussion and
> hear your ideas.
>

OK. The following ideas are somewhat half-baked so don't judge me too
harshly :-).

Rapid deployment of experimental APIs in the browser clashes with our
existing goals. It takes time to negotiate APIs, to create multiple
interoperable implementations, to validate safety, etc. So I conclude we
shouldn't bake them into the browser. Instead we could achieve most of our
goals by enabling third parties to deploy experimental functionality in
browser-independent, device-independent packages that can be used by ---
and if necessary shipped alongside --- Web applications. To the extent we
can do that, we make an end-run around the standardization problem.

For software, this means we need a browser-based execution environment that
can run the code that implements these APIs. I think for C/C++ code, we're
nearly there already. For GPU code the situation is murkier and we need to
solve it (but we already need to).

Hardware is more challenging. I think here it makes sense to have low-level
Web APIs for I/O, e.g. USB. So, when someone produces a sensor/actuator USB
gadget with accompanying software, we should be able to compile the
software for Web use, wrap an API around it that Web apps can use, and host
it in any browser. This hits most of our goals: as long as the package
remains available, there's compatibility; it's device-independent apart
from the dependency on the specific gadget; and it works across browsers
(though there's only one implementation of that specific component).

Safety is a big concern with low-level hardware access. An obvious path
would be to require some kind of trust decision for apps depending
(indirectly) on privileged hardware access, but maybe there's a better way.
For example, when you attach a USB device you're implicitly trusting the
vendor already. What if the browser could extract a vendor domain name from
the device (e.g. via a trusted registry) and granted I/O access to that
device for packages loaded from that domain? A package could claim it
provides a sanitized API to apps, freeing those apps from the trust
decision requirement. When, inevitably, something goes wrong, either the
package is patched or the browser is updated to stop trusting the package.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.