[AG-TECH] VV Spatial metaphor (was AG Security)

Brian Corrie brian.corrie at newmic.com
Thu Sep 26 18:55:46 CDT 2002


Hello all,

I feel the need to reopen this thread in anticipation of the AG2.0 sessions
next week. There are two aspects to the VV metaphor that I would like to see
expanded. One is to make the venues feel more like a workspace. Perhaps this
means a better user interface (as Ivan suggests) and perhaps a better look
and feel (as Jay suggests). My understanding of the original goal of the
venues concept (correct me if I am wrong) was to provide both a scheduled
place to meet as well as a casual place for like minded people to gather. In
many ways this was based on the way the folks at Argonne used their muds. We
use the AG venues using the scheduled meeting metaphor a fair bit but
casual/informal use is not widely used other than to test things. One reason
for this may be that until recently it was difficult to drop in on a venue
from the desktop. Casual interaction is thus unlikely because one has to go
to a physical AG room. Perhaps the PIG and other ligher weight technologies
will help on that front.

The other aspect that needs to be addressed is Ivan's third point. I think
that the rooms need to be more flexible in how they are used. I would like to
be able to populate a venue with the technologies that I want to use for my
meeting and then want the venue to be able to handle the plumbing much like
it does now for audio and video. That is, I want to be able to say my meeting
has a powerpoint component and for the power point file to be distributed to
the remote site and to start automatically like vic and rat do now.
Similarly, I would like to be able to say that my meeting uses higher quality
MPEG 2 video. Or perhaps multipe video streams to which the client can
subscribe. If we can do this in an extensible way (so we can add "arbitrary"
applications) then the AG becomes a very powerful and flexible tool (not that
it isn't already - read that as more powerful and more flexible 8-).

Now I would be a happy camper if I was told we could do all this with AG2.0
8-) If not, then I look forward to the discussions as to how we might be able
to move in that direction...

Cheers,

	Brian


> -----Original Message-----
> From: Ivan R. Judson [mailto:judson at mcs.anl.gov]
> Sent: Saturday, July 20, 2002 5:15 AM
> To: 'Jay Beavers'; 'Tony Rimovsky'; 'Shawn Davis'
> Cc: ag-tech at mcs.anl.gov
> Subject: RE: [AG-TECH] VV Spatial metaphor (was AG Security)
> 
> 
> 
> One question that comes to mind is:
> 
> How do we make the virtual venues "feel" more like real spaces that
> people use to do work?
> 
> Answers:
> 
> 1) Better UI?
> 2) More informal use?
> 3) Better ways to do work in them?
> 
> --Ivan
> 
> ..........
> Ivan R. Judson .~. http://www.mcs.anl.gov/~judson
> Futures Laboratory .~.  630 252 0920
> Argonne National Laboratory .~. 630 252 6424 Fax
>  
> 
> > -----Original Message-----
> > From: Jay Beavers [mailto:jbeavers at microsoft.com] 
> > Sent: Friday, July 19, 2002 4:44 PM
> > To: Tony Rimovsky; Shawn Davis
> > Cc: judson at mcs.anl.gov; ag-tech at mcs.anl.gov
> > Subject: RE: [AG-TECH] VV Spatial metaphor (was AG Security)
> > 
> > 
> > I think there's a strong need for a venue to be more than a 
> > convenient set of IPs to be used for conferencing.  There's a 
> > strong concept of "team portal" that's been growing ever 
> > stronger in the last few years from team sites in Lotus Notes 
> > to Groove to Sharepoint Team Services. This is where a group 
> > of people working towards a common cause share files, 
> > discussions, etc.
> > 
> > If you see my thread back a ways called "Venue What Art 
> > Thou", I suggest that we don't tightly couple the IP 
> > addresses to this team site.  We introduce scalability 
> > problems (# of multicast IPs vs # teams) and administrative 
> > problems (I want a team portal, who do I call to assign an 
> > IP, or I want to use Lotus Notes to store my files but still 
> > use AG for team meetings).  I do suggest that we give Venue 
> > more 'personality' than 'just another IP address'.  By 
> > personality, I mean name, icon, background graphic, etc. so 
> > that people can 'bond' a little with their virtual meeting 
> > space just like they bond with their physical meeting spaces.
> > 
> > 
> > IMHO, we should work towards a solution that allows a Venue 
> > to be easily added to a team portal, while still having both 
> > value and personality when used outside of a team portal.  
> > Trying to replicate team portals inside a Venue would be a 
> > lot of work and would limit AG acceptance with users who 
> > already had a team portal in use.
> > 
> > -----Original Message-----
> > From: Tony Rimovsky [mailto:tony at ncsa.uiuc.edu] 
> > Sent: Friday, July 19, 2002 12:55 PM
> > To: Shawn Davis
> > Cc: judson at mcs.anl.gov; ag-tech at mcs.anl.gov
> > Subject: Re: [AG-TECH] VV Spatial metaphor (was AG Security)
> > 
> > Shawn -- I think your assesment of the current usage is dead 
> > on. Whatever advantages there might be of a spacial metaphor 
> > don't work at all in an environment where the consumers just 
> > wait for the right windows and the node operators fast-click 
> > their way through multiple steps to show the consumer what 
> > they expect to see.  Like changing channels with a remote control.
> > 
> > I think the intention of the AG was to be mud-like, with a 
> > geographic concept and users who can wander around to see 
> > what is going on or go to fixed locations for topical 
> > discussions, like you do in regular office space.  However, 
> > the desire of the consumers is for the AG to be IM-like.  
> > Ad-hoc, point to point or limited many-to-many communication.
> > 
> > Frankly given the idea of personal access grids, using PGP 
> > keys for encryption might work well.  A few of the open 
> > source IM clients can already do this.
> > 
> > 
> > 
> > 
> > 
> > On Fri, Jul 19, 2002 at 01:49:58PM -0500, Shawn Davis wrote:
> > > In a general sense, the AG is a utility to hold video conference
> > meetings 
> > > with multiple locations.
> > > I'm a little bit lost on what the idea of spatial idea 
> > really does to
> > > benefit the experience of the AG.  I may be missing 
> > something critical
> > here 
> > > simply because I've only been involved with the AG for 
> the past year
> > and 
> > > half, and may be missing out on some of the key goals 
> that were set
> > forth 
> > > when the AG idea was created.  But here's how I see it:
> > > 
> > > As it stands right now, I see the process of navigating 
> through the
> > lobby 
> > > to the appropriate venue to be nothing more than that - a process.
> > I'm not 
> > > strolling through the AG virtual world, I'm going to a 
> > virtual venue,
> > a 
> > > destination, for the sole purpose of attending a meeting. 
>  What if I
> > could 
> > > bypass the navigation and simply go straight to my 
> > destination?  This
> > is 
> > > the capability I have provided within AGSchedule.  Because the
> > ultimate 
> > > goal of an AG meeting is to get everyone communicating on 
> > the same set
> > of 
> > > multicast IP addresses, I've created a way to bypass the 
> navigation
> > and go 
> > > straight to your destination.  A time-saving feature, as I see it.
> > Plus, 
> > > you don't necessarily need to know where exactly your 
> > destination is -
> > you 
> > > just go there.  After all, what does it matter?  When you 
> get there,
> > it all 
> > > looks the same.  Everything works the same way.  Your
> > audience/participants 
> > > aren't affected in the slightest bit by where in this 
> virtual world
> > the 
> > > meeting is taking place.
> > > 
> > > Even if the spatial metaphor for virtual venues is 
> further developed
> > into 
> > > something that is more apparent, how does this help the ability to
> > > communicate effectively on the AG?
> > > -Shawn
> > > 
> > > At 12:30 PM 7/19/2002 -0500, Ivan R. Judson wrote:
> > > 
> > > >I like this conversation, but am afraid in both cases (Stephen's
> > example
> > > >and Sean's scheduler) the spatial metaphor is lost.  Spatial
> > information
> > > >(more deeply than the UI metaphor) is integral to the 
> > concept of the 
> > > >venues and the AG as a whole.
> > > >
> > > >The scheduler is a tool to make "formal reservation and 
> > preparation"
> > of
> > > >a virtual space easier.  The goal in the end is what can you do 
> > > >to,in,on,around the space.  The space is implicitly defining the 
> > > >meta-information about multicast groups, users, 
> presence, services,
> > etc.
> > > >Perhaps if we define what the venue is supposed to be (ie, 
> > what data
> > it
> > > >holds, services it provides, etc) that would be a good 
> > first step in
> > the
> > > >process of understanding the appropriate place for various 
> > aspects of 
> > > >security to live in the AG.
> > > >
> > > >This would be a cool place to insert some idea (or 
> > requirement) like:
> > > >
> > > >- The Venue should not be responsible for stream encryption key 
> > > >generation and distribution, or
> > > >- The Venue should be capable of stream encryption key 
> generation,
> > but
> > > >allow participants to use other mechanisms to generate and use 
> > > >encryption keys for stream encryption
> > > >
> > > >There are many other variants, but something concrete like 
> > a set of 
> > > >sentences that represent what people desire might make it 
> > easier to 
> > > >filter through the real issues and find a good clear path out of
> > this.
> > > >
> > > >Thoughts?
> > > >
> > > >--Ivan
> > > >
> > > >..........
> > > >Ivan R. Judson .~. http://www.mcs.anl.gov/~judson
> > > >Futures Laboratory .~.  630 252 0920
> > > >Argonne National Laboratory .~. 630 252 6424 Fax
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: owner-ag-tech at mcs.anl.gov 
> > [mailto:owner-ag-tech at mcs.anl.gov] 
> > > >> On Behalf Of Deb Agarwal
> > > >> Sent: Friday, July 19, 2002 12:18 PM
> > > >> To: s.booth at epcc.ed.ac.uk
> > > >> Cc: ag-tech at mcs.anl.gov
> > > >> Subject: Re: [AG-TECH] AG Security
> > > >>
> > > >>
> > > >> Stephen,
> > > >>
> > > >> Just my 2 cents worth on the topic.
> > > >>
> > > >> We do not have an implementation ready to distribute 
> yet, but we 
> > > >> are working on distributed key agreement that will work 
> > as you say. 
> > > >> The venues server can act as the authorization server 
> > and then the 
> > > >> participants do distributed key agreement using our 
> > protocol.  This 
> > > >> way the venues server only (or whatever you want to use for 
> > > >> authorization) only needs to know public keys that are 
> > authorized 
> > > >> at most and normally only knows distinguished names and 
> > a trusted 
> > > >> CA.  If you want to look at our work so far, the pointer is
> > > >> www-itg.lbl.gov/CIF/GroupComm.
> > > >>
> > > >> Deb
> > > >>
> > > >> S.Booth wrote:
> > > >> > On Fri, 19 Jul 2002, Ivan R. Judson wrote:
> > > >> >
> > > >> >
> > > >> >>Hey Stephen,
> > > >> >>
> > > >> >>I'm not sure I follow your argument below:
> > > >> >>
> > > >> >>
> > > >> >>>This implies that the encryption key is generated by 
> > the venues 
> > > >> >>>server and we therefore have to trust the venues 
> server (not 
> > > >> >>>that we don't trust you but its the principle of the 
> > thing) An 
> > > >> >>>alternative model would be that the meeting organiser 
> > generated 
> > > >> >>>a token for each expected participant containing the 
> > encryption 
> > > >> >>>key and the time of the meeting. The token is public key 
> > > >> >>>encrypted. These can then be stored on the venues 
> > server, sent 
> > > >> >>>by email, stored on a public website whatever.
> > > >> >>
> > > >> >>I think having an automated mechanism for doing key 
> > distribution
> > is
> > > >> >>the goal, whether that's done via the venues server (which
> > > >> makes sense
> > > >> >>in the ivory tower model), or other means is 
> > definitely open to 
> > > >> >>discussion.
> > > >> >>
> > > >> >>
> > > >> >>My personal model for this moving into the future is that a
> > > >> venue is
> > > >> >>something somebody or some group owns.  That means 
> > that person or 
> > > >> >>group can alter "permissions" on the venue, ie, who's 
> > allowed to 
> > > >> >>enter/exit, modify the venue, introduce new applicaions,
> > services,
> > > >> >>etc.  This requires identification and authorization.
> > > >> >>
> > > >> >>Currently, we haven't integrated the notion of users 
> > into the AG 
> > > >> >>completely.  If we did there might be a richer set of data
> > > >> to use for
> > > >> >>exploring different identity and authorization mechanisms.
> > > >> >>
> > > >> >>Getting back to your point, I think it makes infinitely
> > > >> more sense to
> > > >> >>say,
> > > >> >>
> > > >> >>The participants for this private meeting are:
> > > >> >>
> > > >> >>Ivan
> > > >> >>Stephen
> > > >> >>Bob
> > > >> >>Jennifer
> > > >> >>
> > > >> >>And have some mechanism in place to "lock" other
> > > >> participants out of a
> > > >> >>venue, in addition to "throwing them out" of a venue they
> > > >> don't belong
> > > >> >>in.  In addition, I think the metaphor is "private 
> > meeting" not 
> > > >> >>"encrypting streams", the mechanisms for making a 
> > meeting private 
> > > >> >>include encrypting streams, but also allocating different
> > multicast
> > > >> >>addresses for each meeting, or perhaps other more creative
> > things.
> > > >> >>
> > > >> >>Does that make sense?
> > > >> >>
> > > >> >>--Ivan
> > > >> >>
> > > >> >>PS -- I don't find the ACL to be the problem in the current
> > > >> model, I
> > > >> >>find the problem is Bob is the only one who can edit it to
> > > >> be the real
> > > >> >>problem :-).  That being said, we've just institued a
> > > >> policy whereby
> > > >> >>bob no longer can have vacation since he's so 
> critical to this 
> > > >> >>part...NOT
> > > >> >>
> > > >> >
> > > >> >
> > > >> >
> > > >> > I think you are entirely right about the model for the user
> > > >> interface
> > > >> > model. You integrate with a booking system and select
> > participants
> > > >> > from the database. The nsca scheduler already does 
> > this. I'm more 
> > > >> > concerned with how you would implement this interface 
> > in a secure 
> > > >> > fashion. OK the probability of someone trying to break AG
> > > >> is low but
> > > >> > cryptography is fun.
> > > >> >
> > > >> > Imagine you modify the ncsa scheduler to optionally supply
> > > >> a randomly
> > > >> > generated session key to booked sessions. Lets think how you
> > would
> > > >> > break this system. Assuming we don't have the compute power
> > > >> to brute
> > > >> > force the session key the next obvious step is to try to
> > > >> hack into a
> > > >> > system that has the key. Obviously any one of the meeting
> > > >> participants
> > > >> > would do, but if the key was originally generated by the
> > scheduler
> > > >> > this becomes the most attractive target to attack as you
> > > >> could subvert
> > > >> > the code that generated the key and gain access to 
> ALL private 
> > > >> > sessions. On the other hand if the scheduler only holds a
> > > >> database of
> > > >> > public-keys for AG users and public-key encrypted 
> session keys
> > are
> > > >> > generated on the home machine of the person making 
> the booking
> > then
> > > >> > uploaded to the scheduler the user interface looks 
> the same but
> > the
> > > >> > security risk is much less.
> > > >> >
> > > >> > Of course this is probably overkill for most AG users.
> > > >> Maybe we should
> > > >> > just lobby for a single dialog box on the event server 
> > to make it 
> > > >> > easier to set the session key by hand, then tell people to
> > exchange
> > > >> > keys by secure email. If you are not paranoid you probably
> > > >> don't care
> > > >> > about encryption. If you are then you won't trust an
> > > >> automated system
> > > >> > anyway :-)
> > > >> >
> > > >> >
> > > >> >
> > > >> >                             Stephen
> > > >> >
> > > >>
> > 
> ======================================================================
> > > >> > |epcc| Dr Stephen P Booth             Project Manager
> > > >>     |epcc|
> > > >> > |epcc| s.booth at epcc.ed.ac.uk          Phone 0131 650 5746
> > > >>     |epcc|
> > > >> >
> > > >>
> > 
> ======================================================================
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > >> ~~~~~~~~~
> > > >> Deb Agarwal                          e-mail:DAAgarwal at lbl.gov
> > > >> MS50B-2239                           phone :(510)486-7078
> > > >> Lawrence Berkeley National Lab       URL:
> > http://www-itg.lbl.gov/~deba
> > > >> Berkeley, CA 94720 
> > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > >> ~~~~~~~~~
> > > >>
> > > 
> > 
> 
> 



More information about the ag-tech mailing list