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> 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> 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 > > > > > >
