Re: Sandbox

On Mon, Sep 17, 2012 at 2:21 PM, Joran Greef <joran@ronomon.com> wrote:

> Apps (native/web) need direct access to bare metal.
>
> Browser vendors need to move away from the "we do all the thinking and
> designing and implementing" top-down model of innovation.
>
> Browser vendors need to provide minimal core OS APIs and get out of the
> way and let open source grow around and do the rest.
>
> For too long now the typical response to this kind of proposal has been
> "how do you propose solving the security problems?"
>
> That is to say, we should not do any of this unless we can perfectly solve
> the security problems. As if they can be perfectly solved.
>
Security is a pretty serious concern if you're distributing apps without
any oversight to billions of users automatically upon a single link click.


> And so our most perfect solution has been to completely cripple web apps:
>
> No TCP.
>
Wrong, see websockets which upgrade to plain old TCP after the handshake.


> No UDP.
>
Coming with WebRTC in the form of unreliable data channels.


> No POSIX.
>
Why would you need cross-OS posix standards and operating system shells
when you already have a browser which abstracts cross-OS APIs in its own
fashion?


> No Hardware.
>
Wrong, see pointerLock APIs, audio data APIs, WebGL, input device APIs
(like gamepads).


> Tim Berners-Lee raised this point first awhile back on Public Web Apps:
> http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html

I believe his point was subtly different. He was arguing for vendors to
come up with ways to solve the usecases he mentioned, not arguing to just
blast the OS at the JS developer and let the ensuing security
armageddon sort itself out.


> As a user, I want to write a web app. I trust it. I want to give it UDP,
> TCP and POSIX anointing. I want it to use the resources of my machine to
> act on my behalf and assist me in my work. The browser won't let me. Why?
>
Because security.