Re: What I am missing

I am not sure if I understand your question. Browsers can't be code 
servers at least not today.

Michaela



On 11/19/2014 08:43 AM, Pradeep Kumar wrote:
>
> How the browsers can be code servers? Could you please explain a 
> little more...
>
> On 19-Nov-2014 7:51 pm, "Michaela Merz" <michaela.merz@hermetos.com 
> <mailto:michaela.merz@hermetos.com>> wrote:
>
>     Thank you Jonas. I was actually thinking about the security model of
>     FirefoxOS or Android apps. We write powerful "webapps" nowadays. And
>     with "webapps" I mean regular web pages with a lot of script/html5
>     functionality. The browsers are fast enough to do a variety of things:
>     from running a linux kernel, to playing dos-games,  doing crypto,
>     decoding and streaming mp3. I understand a browser to be an operating
>     system on top of an operating system. But the need to protect the user
>     is a problem if you want to go beyond what is possible today.
>
>     I am asking to consider a model, where a signed script package
>     notifies
>     a user about is origin and signer and even may ask the user for
>     special
>     permissions like direct file system access or raw networking
>     sockets or
>     anything else that would, for safety reasons, not be possible today.
>
>     The browser would remember the origin ip and the signature of the
>     script
>     package and would re-ask for permission if something changes. It would
>     refuse to run if the signature isn't valid or expired.
>
>     It wouldn't change a thing in regard to updates. You would just
>     have to
>     re-sign your code before you make it available. I used to work a lot
>     with java applets (signed and un-signed) in the old days, I am working
>     with android apps today. Signing is just another step in the work
>     chain.
>
>     Signed code is the missing last element in the CSP - TLS environment .
>     Let's make the browser into something that can truly be seen as an
>     alternative operating system on top of an operating system.
>
>     Michaela
>
>     On 11/19/2014 08:33 AM, Jonas Sicking wrote:
>     > On Tue, Nov 18, 2014 at 7:40 PM, Boris Zbarsky <bzbarsky@mit.edu
>     <mailto:bzbarsky@mit.edu>> wrote:
>     >> On 11/18/14, 10:26 PM, Michaela Merz wrote:
>     >>> First: We need signed script code.
>     >> For what it's worth, Gecko supported this for a while.  See
>     >>
>     <http://www-archive.mozilla.org/projects/security/components/signed-scripts.html>.
>     >> In practice, people didn't really use it, and it made the
>     security model a
>     >> _lot_ more complicated and hard to reason about, so the feature
>     was dropped.
>     >>
>     >> It would be good to understand how proposals along these lines
>     differ from
>     >> what's already been tried and failed.
>     > The way we did script signing back then was nutty in several
>     ways. The
>     > signing we do in FirefoxOS is *much* simpler. Simple enough that no
>     > one has complained about the complexity that it has added to Gecko.
>     >
>     > Sadly enhanced security models that use signing by a trusted party
>     > inherently looses a lot of the advantages of the web. It means that
>     > you can't publish a new version of you website by simply uploading
>     > files to your webserver whenever you want. And it means that you
>     can't
>     > generate the script and markup that make up your website dynamically
>     > on your webserver.
>     >
>     > So I'm by no means arguing that FirefoxOS has the problem of
>     signing solved.
>     >
>     > Unfortunately no one has been able to solve the problem of how to
>     > grant web content access to capabilities like raw TCP or UDP sockets
>     > in order to access legacy hardware and protocols, or how to get
>     > read/write acccess to your photo library in order to build a photo
>     > manager, without relying on signing.
>     >
>     > Which has meant that the web so far is unable to "compete with
>     native"
>     > in those areas.
>     >
>     > / Jonas
>     >
>
>
>