It's pretty.
Thanks, I try...
Here's how I'd thought of it, without bringing it down to
a trust template.
We need to know on whose behalf the proxylet operates,
who vouches for its intended operation, and what
resources it requires. Local resources are CPU cycles,
memory, transient and permanent objects, policy rules,
connections, trust credentials, and network information.
After that, it's all policy.
Well, when I put this together I was going for a framework to discuss a
'working environment' and usage model - trust is a whole new bailiwick.
Let's start diving into it.
Proxylets can travel along the content path; whether or not they
are accepted depends on the policy of the boxes they pass
through. The boxes are concerned about privacy and
authorization and resource control.
A proxylet, if installed as a resident object, in accordance
with local policy, gets the privileges associated with
more local policy.
Okay, first I want to say I'm not all together convinced that having
proxylets coming along the proxy path is all that great of an idea. I'm
sure we've all gone through the litany of problems with this - trust, of
course, but also verifying that a OPES-enabled box is somewhere downstream.
I realize that the OPES standard as it exists today has this feature, but I
still think that nearly all of the features that we have come up with to
date would be enabled on a box by the administrator/owner of the box.
If we start talking about setting up trust agreements, and business
arrangements, it seems more likely that the proxylets/rules will be given to
the owner (through some undefined process) and then placed on the OPES box.
Right now I think there is enough functionality with this model to get some
real value added - I'm afraid the dynamic loading of proxylets along with
content might lead us down a path towards something that is either
unimplimentable, or if implemented would be turned of in the interest of
security.
Perhaps a second discussion thread on the pros & cons of implementing
proxylets along the content stream is in order.
A typical kind of policy will be to honor agreements with a
CDN to let proxylets of certain types run as part of the
OPES environment. The CDN signs the proxylet or
provides an authenticated service for verifying a hash
of the proxylet. It gets to run, but with certain restrictions
that local adminstrators set. It can open connections
to sites that are part of the CDN, it can install authenticated
redirection policy to that CDN, it can access hit counts
and byte count information associated with that CDN.
I agree, and I think this is where the CDN has a great advantage in
implementing OPES - the CDN can guarantee to the content provider that all
of the content will go through their boxes.
My suspension is, though, that the CDN will reach an agreement with the CDN
to either let them use a service that the CDN implemented/bought running on
OPES boxes, or if a content provider wants a service implemented then it is
given to the CDN and deployed through an administrative box (rather than
along the content flow).
The hit count stuff, etc. is part of the standard API that a
proxy presents to OPES services. So are the redirection
rules. Proxylets can extend the basic services for use
by related proxylets, and URL's provide ways to retrieve
proxylets that have gone missing.
I agree - I think we need to get more discussion going about the API that is
available to a proxylet (by type? One API for java, one for perl? Lots of
questions here).
Perhaps we need to define explicit roles and trust
levels. Some proxylets will originate locally and
be fully trusted, others will be from partners with
mutual interests, others will be transient and subject
to low priority/low privilege.
This is why whenever a discussion of proxylets comes up, Java always seems
to be implied, particularly because of it's sand-box features. Currently,
however we are slated to support several languages - any thoughts on how we
can control/limit non-java languages? I am told Microsoft's .net is
supposed to support multiple languages using a VM, but I know very little
about it.
-Rob