[cap-talk] Polaris tickle, POLA for Internet access, URLs

Jed Donnelley jed at nersc.gov
Mon Dec 6 21:50:53 EST 2004


At 05:48 PM 12/6/2004, David Wagner wrote:
>Jed writes:
> >>David Wagner wrote:
> >>>I believe by far the largest source of security holes is in the
> >>>specification (of desired functionality), not necessarily in the
> >>>implementation.  For instance, take Javascript.
> >
> >Specifically by limiting the rights of the process interpreting
> >the Javascript to essentially the ability to read the input data and
> >the ability to generate a pixel map with links to be displayed.
>
>But then it wouldn't be Javascript anymore; it would be some poorly
>designed scripting language with lame syntax that has suddenly been
>rendered useless to web developers.  (As opposed to Javascript today,
>which is a poorly designed scripting language with lame syntax that web
>developers consider very useful.)
>
>With the changes you suggest, existing web pages would no longer work.
>Existing features could not be supported by this new language.  (To give
>a simple example, consider a button that changes color when your mouse
>passes over it.)  Web developers would scream bloody murder.

Good point.  I can see that my first blue sky idea had a serious flaw.
Thanks for pointing it out.  However, I don't believe that problem is
fundamental to the architectural separation I suggested (below).

>It's not much of a solution.  It would be simpler just to ditch Javascript
>entirely.  The only reason that web developers like Javascript is because
>it gives them so many powers.  If you remove those powers, they won't be
>happy any more, and you won't be able to support lots of the functionality
>they like to provide.

I believe (correct me if I'm wrong on this - I've written some Javascript,
but not much) that most of the value that you refer to comes from
the ability to manipulate the user interface - not in any flexibility
to communicate on the Internet.  With the sort of architecture I
suggested there would be no problem having the Javascript
interpreter run in a process that has direct access to its source
Internet site *and* to the displayed window, user input (e.g.
mouse overs, etc.).

I guess where push would come to shove would be where there
could be potential confusion of the user with regard to the site
that was being designating.  E.g. if the URL linked to could change (e.g.
be time dependent as I have seen) in such a way as to be ambiguous.

I believe a potential restriction would be to fix the map between
pixel locations and links.  This would indeed be a restriction on
Javascript, but perhaps not so serious a one as you believed
to begin with?  The pixels themselves could change in any
dynamic way including mouse overs or whatever.

>So I'm back to where I started.  I believe it is the specification of
>the desired functionality that is the problem, not the implementation
>strategy for supporting that functionality.  I can't see any way to
>provide the web developers with what they want and still retain security,
>and ...

I can agree that there is a problem of specifying the desired
functionality.  However, I argue the main reason this is a problem
is because of the overly powerful position that any process finds
itself in when running on todays systems.  When a language like
Javascript was designed the premium was placed on making
available all the power of the underlying interface, no matter
what the consequences for security.  I believe that relatively
little thought about what sorts of rights are suitable for parts
of a Web browsing package can result in a modularization
with capability (object) communication between the parts
that would be both secure and provide nearly all the reasonable
flexibility in user interface control that Javascript supplies.

Perhaps Javascript would be broken enough by such
restrictions that you're right and it would need to be
abandoned.  I don't believe so, but it's possible.  However,
when you say:

>  ... I don't see how capabilities changes that conclusion in any way.

I believe you go way too far.  Firstly, an effective capability
computing environment would provide exactly the sort of
restricted execution environment that the Polaris folks
need for the sort of work they were doing.  I claim that
such an environment is also exactly what is needed to
develop a secure browsing mechanism.  Without that base
restricted execution environment you can't even begin
to build the safe browsing mechanism.

With the ability to restrict parts of the browsing mechanism
to access to particular objects I believe it becomes clear
where the lines need to be drawn.  If you find that even with
a suitable restricted execution environment and object
oriented access control you are still unable to define
an effective set of interfaces for a language like Javascript,
then perhaps we should take up that topic on another
thread.  I'd be interested in discussing it with you.
Perhaps we could examine specific Javascript functions
and see which conflict with the needs of a user to
be able to be clear in specifying a link.  That doesn't
seem to be a topic for cap-talk.

--Jed http://www.webstart.com/jed/ 



More information about the cap-talk mailing list