Re: What I am missing

2014-11-19 Thread Pradeep Kumar
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.


 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
  It would be good to understand how proposals along these lines differ
  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
  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

Re: CfC: publish WG Note of UI Events; deadline November 14

2014-11-19 Thread Pradeep Kumar
On 19-Nov-2014 8:07 pm, Anne van Kesteren wrote:

 On Wed, Nov 19, 2014 at 3:20 PM, Arthur Barstow
  Although there appears to be agreement that work on the [uievents] spec
  should stop, the various replies raise sufficient questions that I
  this CfC (as written) as failed.
  Travis, Gary - would you please make a specific proposal for these two
  specs? In particular, what is the title and shortname for each document,
  which spec/shortname becomes the WG Note?
  After we have agreed on a way forward, I'll start a new CfC.
  (I believe the Principle of Least Surprise here means considering specs
  currently reference [uievents] or [DOM-Level-3-Events]. F.ex., I suppose
  document titled UI Events with a shortname of DOM-Level-3-Events could
  a bit confusing to some, although strictly speaking could be done.)

 My proposal would be to update UI Events with the latest editor's
 draft of DOM Level 3 Events (title renamed, of course) and have the
 DOM Level 3 Events URL redirect to UI Events. That would communicate
 clearly what happened.


Re: What I am missing

2014-11-19 Thread Pradeep Kumar
Even today, browsers ask for permission for geolocation, local storage,
camera etc... How it is different from current scenario?
On 19-Nov-2014 8:35 pm, Michaela Merz wrote:

 That is relevant and also not so. Because Java applets silently grant
 access to a out of sandbox functionality if signed. This is not what I am
 proposing. I am suggesting a model in which the sandbox model remains
 intact and users need to explicitly agree to access that would otherwise be


 On 11/19/2014 12:01 AM, Jeffrey Walton wrote:

 On Wed, Nov 19, 2014 at 12:35 AM, Michaela Merz wrote:

 Well .. it would be a all scripts signed or no script signed kind of
 deal. You can download malicious code everywhere - not only as scripts.
 Signed code doesn't protect against malicious or bad code. It only
 guarantees that the code is actually from the the certificate owner ..
 has not been altered without the signers consent.

 Seems relevant: Java's Losing Security Legacy, and Don't Sign
 that Applet!,

 Dormann advises don't sign so that the code can't escape its sandbox
 and it stays restricted (malware regularly signs to do so).