- Security: Proposal to add a hook ("oaa_ValidateEvent") allowing
agent
library and agent programmer to check event before blindly accepting
to
execute it.
- Some discussion on Priorities of events and Threaded Messages
-------------------------------------------------------------------------
> I like these proposals, they seem quite general, and they have obvious
> advantages over the current system.
> But they do bring up one general concern, which is that an agent is
> extremely vulnerable to misguided or malicious control events arriving
> from other agents.
> This the case not only for requests for flushing of queued events, but
> also for requests to add and remove triggers (as discussed in other
> messages).
>
> I don't have a clear answer to this. But perhaps something simple would
> go a long ways. Perhaps one of these:
>
> (1) Each agent could specify from which other agents it will accept
> event flushing or trigger requests.
>
> (2) When an event flush or trigger request arrives, it could be handled
> by a locally defined handler, if one has been defined. Such a handler
> would give an agent developer a place to write code to verify that it
> makes sense to comply with the arriving request. If the handler is not
> defined locally, then a default handler, provided by the agent library,
> could be used.
David, you bring up an excellent but complicated point. Maliciousness is
not
contained to just flushing or trigger events -- MANY types of events
could do
harm or compromise security. Security is a very hard issue because it
involves:
-- Authentication of the sender, to be sure someone is not
maskerading as
another trusted agent.
-- Authentication of the message contents, to make sure someone
hasn't tampered
with it along the way.
-- Encryption, so others can't spy on your private data
-- Restriction of events to guaranteed harmless events.
-- etc.
It's clear that security is a vital issue, but I don't think it's one we
are
going to solve in this version of the research system.
However, I DO propose that we add a primitive
"oaa_ValidateEvent(InComingEvent, OkEvent)"
which will be immediately called on the arrival of event. This
predicate has the
option of refusing to accept the event entirely (by failing), or of
modifying the event
in some way to produce an acceptable version of it (e.g. by removing the
flush
parameter, by setting limits on the priority value, ....). Some checks
will be built
into the agent library (one day we can do event authentication, etc.)
and if the
event passes library-level tests, the event can be further tested at the
agent level
with the callback oaa_AppValidateEvent().
Keith had some good remarks about priorities:
> I concur with David Martin's observations, and would extend that one
> further: who is it that defines the priority of any given event?
> An agent would have to know a priori to set a higher priority on an
> event that is a response to a blocking request issued by some other
> requesting agent. That is, both the agents have to agree on the set of
> priority values and what they mean, reducing the generality of the
> agents themselves somewhat. In effect, the proposal implements a small
> "sequencing tag" protocol (modulo the flush behavior).
It is true that the proposed scheme is not extremely sophisticated;
rather it is intended
to be a little more general than the current scheme, and to address
several concrete
problems. In general, most events are not expected to have priorities,
but there may
be several specific reasons for having them. Perhaps we could remove
some confusion by setting
priorities in symbolic terms instead of numerical terms:
- default (5): blocking solves are not interrupted by other events
- interrupt_blocking (7): a higher priority event that will start
executing on an agent
even while it's waiting for the return of a blocking solve
- immediate (10): highest priority, should jump ahead of all other
events in the queue and
execute immediately
- not_busy (3): a low priority event that should not take up cpu time
ahead of other tasks
but could be executed only when no other events are in the queue.
Erland, Keith and David had some comments about threaded message
retrieval:
In the Java library, each blocking solve creates a new thread to wait
for the answers.
One problem noted is that we don't have a unique ID associated with
outgoing and
incoming messages, guarantee that they match: if two threads send
unifyable requests,
some confusion could occur. One good proposal is that we add this ID to
the solve
events to guarantee the match. Erland also proposed that the ID could
be used as a
hash function to quickly match an incoming event to the correct thread.