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.m...@hermetos.com <mailto:michaela.m...@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 <bzbar...@mit.edu
    <mailto:bzbar...@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
    >




Reply via email to