Firefox security strategy (was: Firefox goodies)

[Ben Scott]

On 12/29/05, Kevin D. Clark <kevin_d_clark at comcast.net> wrote:
> So do you like a security model or not?  To me you're sending mixed
> signals here.  To me, a system that is designed from the ground up with
> security in mind has a security model.

  What I'm trying to get at (albeit not clearly) is that things like
Java and the JavaScript document security model or whatever it is
strike me as the wrong way to do it.  In both cases, we're building a
very capable, general-purpose programming language, and then trying to
figure out where we need to put the leg irons on to keep it safe. 
Maybe we intended all along to put the leg irons on, and we have this
elaborate system of keeping track of the leg irons and building leg
irons, but ultimately, it still comes down to building capabilities
and then trying to take them away.  After watching the disaster that
has been web browser security unfold for the last several years, I'm
pretty well convinced that isn't the right way to do things.  If you
don't want your creation to walk away, don't give it legs in the first
place.

> I'm pretty sure we both agree that security by design is better than a
> "let's bolt on some security later!" scheme.

  Certainly.  I'm just going beyond that.

> Sounds like you'd like a better/more-well-designed JavaScript.

  A JavaScript that was designed at all would be a good start.  ;-)

>>   And on the gripping hand, none of this solves the problem of buffer
>> overflows and other stupid implementation mistakes that even Firefox
>> suffers from.
>
> Java and applets were better than most in this respect.

  Well, things done in Java certainly don't suffer from the "buffer
overflow leading to code injection" problem[1].  But I've never felt
entirely comfortable with the suggestion that "stupid implementation
mistakes that lead to security holes" is a problem limited to a lack
of language-enforced bounds checking.  Also known as "Blame everything
on C syndrome".  These mistakes are sufficiently stupid that I
strongly suspect implementing everything in Java/Python/whatever would
just trade one set of security holes for another.

[1] Well, ignoring the holes found in Java VM implementations on a
semi-regular basis.

> 1:  If JavaScript was better/safer/more-consistant/portable this would
>     be a good thing.

  Absolutely.  Can't argue with that.

> 2:  OTOH, I'd hate to clamp down so much on the design of JavaScript
> (or some future replacement) such that some interesting service/feature
> couldn't be realized by this technology.

  While I understand the sentiment very well, and indeed like and use
that quote myself, the pragmatic part of my personality wants to step
in and say, "That's all very well and good, but I'd really like to be
able to read a newspaper without fear that the ads on the bottom are
going to steal my wallet when I'm not looking".  The needs of security
are sometimes opposed to the desire for cleverness.

  In other words, maybe we're better off without some of the
potentially clever things that could be done with
JavaScript/Java/whatever, if it yielded a safer web.

> And, so, here we are.

  And where is that, again?  ;)

-- Ben