[cap-talk] Polaris tickle, POLA for Internet access, URLs
jed at nersc.gov
Mon Dec 6 21:50:53 EST 2004
At 05:48 PM 12/6/2004, David Wagner wrote:
> >>David Wagner wrote:
> >>>I believe by far the largest source of security holes is in the
> >>>specification (of desired functionality), not necessarily in the
> >Specifically by limiting the rights of the process interpreting
> >the ability to generate a pixel map with links to be displayed.
>designed scripting language with lame syntax that has suddenly been
>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 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.
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
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
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,
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
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
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
then perhaps we should take up that topic on another
thread. I'd be interested in discussing it with you.
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.
More information about the cap-talk