[cap-talk] getting authorization from the user and the great insight

[Karp, Alan H]

Jed wrote:
> > 
> > Whether it's a good idea to "harvest" knowledge from user actions
> > depends on what you mean by "harvest".  In Jed's example, the action
> > of drawing a line seems arbitrary and unrelated to authorization.
> 
> Exactly.  Let me mention a few more.  All the typing of
> text in this message that I'm typing.

Actually, typing in the window containing the text could be a good way
to denote that you want to grant write authority to a file previously
opened read only.  That presumes, of course, that we know it's the user
doing the typing and not some script.
> 
> > But what is the context of the action?  If the line represents a
> > relationship that inherently requires an access grant, triggering
> > authorization doesn't seem so farfetched.  What if the diagram is
> > a depiction of projects and subprojects, and drawing the line from
> > X to Y means that the purpose of subproject X is to achieve a
> > subgoal necessary to project Y?  Then perhaps the team working on
> > project Y should gain access to the documents in subproject X.
> 
> To me this feeds directly into the point I was trying to make.
> It is vitally important to me as the user to know the difference.
> Most of my actions at a computer I assume (hope to know) are
> not to result in "authorizations" in the sense I defined
> at the end of my last paragraph.
>
This is where context comes in.  Are we talking about a graphical
programming environment or one for documentation?  In the former case,
we probably want to grant authority in the "import package" sense.  In
the latter, we don't.  How do we connote the difference?  Ah, there's
the rub.
 
________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp
  
  

> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Jed Donnelley
> Sent: Thursday, October 04, 2007 8:34 PM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] getting authorization from the user 
> and the great insight
> 
> On 10/4/2007 4:13 PM, Ka-Ping Yee wrote:
> > John Carlson wrote:
> >> My question is, is every action the user makes authorization?  For
> >> example, does drawing a line give the system authorization 
> to change
> >> an image?  Or does opening the image give the user the 
> authorization
> >> to draw a line?   What draws the line between something 
> that requires
> >> authorization and what doesn't?  Or is authorization something that
> >> is inherent in the design?
> > 
> > I'll weigh in here.
> 
> Thanks Ping, I was hoping you would.
> 
> > Every action the user makes is a command.
> 
> That far I'm with you.
> 
> > In an ideal design, commands and authorizations are the same thing.
> 
> Interesting.  I think perhaps I can see how you may be
> interpreting "authorization" loosely enough to make the
> above sentence make sense.  I don't generally interpret
> it that that way, but perhaps I need to have my horizons
> (definition?) broadened.  I'll state my viewpoint
> below where it seems more appropriate.
> 
> > For example, suppose you have a personal assistant who takes care of
> > things for you.  You say, "Please return these library 
> books for me."
> > This is a command and also an authorization -- it is reasonable that
> > this authorizes your assistant to take possession of the 
> library books,
> > since that is inherently required by the command.
> 
> I can see that.  However, in my experience for the vast
> majority of actions I take on computer systems I do
> not intend them as authorizations and I hope they
> won't be interpreted that way (e.g. "harvested"
> for such a purpose).  More below.
> 
> > Jed wrote:
> >> It seems to me that any effort to "harvest" all
> >> (or even only some not explicitly designated user
> >> actions) for authorizations is that it would create
> >> a seriously conflicted and confusing situation with
> >> regard to how users view their actions.  For example,
> >> I don't want to have to worry that drawing a line
> >> from one project icon to another in a project
> >> management program might inadvertently cause some
> >> potentially unwanted authorization to happen.
> > 
> > Whether it's a good idea to "harvest" knowledge from user actions
> > depends on what you mean by "harvest".  In Jed's example, the action
> > of drawing a line seems arbitrary and unrelated to authorization.
> 
> Exactly.  Let me mention a few more.  All the typing of
> text in this message that I'm typing.  Almost any other
> set of actions intended to do "editing" (e.g. text,
> multimedia, etc.).  My example above was intended to
> be intermediate between such purely graphical editing
> and something at a slightly higher level (e.g.
> picturing projects).  Moving a slider up and down
> on the side of a browser window.  Moving a window
> from one position to another on my desktop.  Adjusting
> the volume or contrast in an application. ...
> 
> The examples of actions that I hope are not considered
> as authorizations goes on and on.  It is the ones that
> are interpreted as authorizations that I hope are few
> and well understood.
> 
> However, ...  I can understand a possible interpretation
> of the term "authorization" to include the above.  For
> example, my pressing of the "a" key that resulted
> in the entering of that "a" into this text could be
> interpreted as an authorization for my email client
> to insert the character "a" at the above point where
> the cursor was pointing.  To me such a general
> interpretation of the term "authorization" makes
> that word almost meaningless.  The working definition
> that I am using for the term "authorization" is the
> act of granting a running program (active object)
> access to something (the ability to take some action)
> that it didn't previously have.
> 
> > But what is the context of the action?  If the line represents a
> > relationship that inherently requires an access grant, triggering
> > authorization doesn't seem so farfetched.  What if the diagram is
> > a depiction of projects and subprojects, and drawing the line from
> > X to Y means that the purpose of subproject X is to achieve a
> > subgoal necessary to project Y?  Then perhaps the team working on
> > project Y should gain access to the documents in subproject X.
> 
> To me this feeds directly into the point I was trying to make.
> It is vitally important to me as the user to know the difference.
> Most of my actions at a computer I assume (hope to know) are
> not to result in "authorizations" in the sense I defined
> at the end of my last paragraph.
> 
> If some of my actions are to be interpreted as authorizations
> in the above sense then I have a potentially higher vested
> interest in making sure the program responding to my actions
> interprets my actions as I intend, so I want to be sure I know
> what those actions are and how they will be interpreted.
> 
> > In other words, it all comes down to mental models.  It's 
> not so much
> > whether "harvesting" is taking place as whether the 
> authorization fits
> > the user's model of how interactions are being interpreted.
> 
> - which for me means it is that much more important to
> insure that the user's mental model of what authorizations
> will correspond to which of their actions and the authorization
> actions of the program responding to the user's actions
> coincide.
> 
> I definitely do not want programs that may be aware of
> my actions that I do not consider authorizations to
> be "harvesting" some of those actions and interpreting
> them as authorizations.  I just moved the slider on
> my email window down.  I don't want that to result in
> an authorization any more than I want this typing to
> do so - at least with my interpretation of the term
> "authorization."
> 
> What I want is clarity of the model.  I want to know
> exactly which of my actions the program that responds
> to them will consider as authorizations and for what.
> 
> I think the CapDesk example:
> 
> http://video.google.com/videoplay?docid=-7961423532989255419#20m16s
> 
> is particularly good in this area:
> 
> 1.  If I double click on an object, it makes sense to me
> that the application associated with an object of that
> type will be given access to the object (e.g. a file).
> 
> 2.  If I drag an object over and drop it on an application
> icon (or window), it makes sense to me that the program that
> is initiated (or is running) would be given access to that
> object.
> 
> 3.  If in a "Power Box" open object (e.g. file) dialog
> window I grant access to some object to an application
> named in the window (as in the CapDesk example), it makes
> sense to me that I would be granting the application
> access to the object.
> 
> 4.  If I copy and paste a link (capability, reference)
> to an object into an application window or onto an
> application icon (e.g. into the "location" window in
> a capability browser), it makes sense to me that I would
> be granting the application access to the object.
> 
> 5.  If one object contains the rights to other objects
> (e.g. as a directory object might contain rights to
> files or other directories within it), it makes
> sense to me (though others might have to learn this model)
> that by granting an application access to the container
> I'm also granting the application access to what's
> inside the container.
> 
> For me actions like the above are all I've ever needed.
> I can certainly imagine other possibilities, but I'd
> want to be very clear just which actions were going
> to be interpreted as authorizations and what authorizations
> would take place in response to those actions.
> 
> I believe in the KISS principle, particularly when
> applied to something like authorizations (in the
> sense I've used it - possibly more narrow than your
> intended meaning?)
> 
> I get very concerned when somebody tells me that they
> want to "harvest" all my actions and interpret them
> as authorizations.
> 
> Please tell me why I shouldn't be concerned, but rather
> should learn to love such a harvester implementing the
> great insight.
> 
> --Jed http://www.webstart.com/jed/
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>