How the browsers can be code servers? Could you please explain a little
On 19-Nov-2014 7:51 pm, "Michaela Merz" <> 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 <> 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
> >> <
> >.
> >> 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