[AG-TECH] VV Spatial metaphor (was AG Security)
Ivan R. Judson
judson at mcs.anl.gov
Sat Jul 20 07:15:23 CDT 2002
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