[cap-talk] Another "core" principle

[Marc Stiegler]

Jonathan S. Shapiro wrote:

> This is all true, but completely irrelevant. The type of intertwining
> that concerns me does not arise from cruddy engineering. It arises from
> the fact that real users in real systems are going to build *documents*
> consisting of intertwined capbilities. It is not the underlying
> applications that are unstructured. Rather, the claim is that in an
> object system the natural content model for document-like content is an
> intertwined space of capabilities.
> 
> Regarding your claim that this hasn't been seen in the field: perhaps
> you haven't heard of the MS Object Linking and Embedding protocol.
> 
> In OLE, the bad effect results from files being deleted rather than
> capabilities being severed, but the end result is precisely the same.
> For document transmission, application authors have been forced to bad
> expedients such as caching a WMF image in the document containing the
> OLE link source. Meanwhile, users have learned that out-of-document
> object references cannot be relied on.
> 
> I claim that not only is the problem real, but it has been observed
> continuously in the wild for at least 10 years, and it is the single
> greatest impediment to the utility of OLE.
> 
> Fundamentally, the OLE problem is a failure of GC and object reference
> preservation of exactly the type I anticipate will occur under membrane
> revocation.

Great example problem, and I agree that I was answering the wrong 
question earlier. Let me break this down into 2 problems that we can 
discuss independently:

-- Problem 1: Document composition has some hard problems for which the 
Windows solution is inadequate, and caps don't help.

-- Problem 2: With a cap system, document composition will be a more 
common, more popular pattern. Therefore, without a better solution to 
problem 1, the resulting system of mixing docs with caps will be a 
solution that is worse for the user.

You may find my answers to both these problems inadequate. I find my 
answers barely satisfactory, and look forward to having a caps-oriented 
desktop with which to experiment some day, to build better answers.

Answer to question 1: do caps help with document composition? The answer 
is, it sometimes helps, but not often enough to make one feel great. In 
my current visualization of a real CapDesk, the concept of "document" in 
Windows is separated into 2 distinct notions: a "live document", which 
is the persistent state of a document+app and a "dead document" that is 
just data. On windows, this distinction is partially implemented in the 
difference between rtf (dead) and doc (live) files: rtf is just the data 
for the document, but the doc file remembers various state features, 
such as the size, shape, location of the window, and where the cursor 
was in the file. On CapDesk, a live document remembers its state, which 
includes all its authorities. So if I send you a reference to my live 
doc, or a copy of my live doc, a correct implementation will send either 
a ref with all the auths, or a copy of all the things at the ends of all 
the auths. In other words, if I send you a copy of the live document, 
you will receive a copy of all the documents in the composition. But if 
I send you a copy of the dead document, you have the traditional OLE 
problem.

Answer to question 2: Truthfully, I can't get myself worked up over this 
problem because the answer to problem 2 is, people will work at a level 
of abstraction, and a level of granularity, that works well for them. 
Humanity has done experiments with level of granularity at which to 
handle data and docs in the past, and the answer always winds up being, 
people gravitate to something coarse enough to handle easily, and fine 
enough to be useful in the context of the project being undertaken. 
StarOffice aggregated office apps too coarsely, and Open Office fixed 
that. There were products for the Mac in the late 80s that tried to 
compose larger documents from smaller ones, and they failed because they 
were too small to handle easily (I can't even remember the names any more).

With caps, the natural level of abstraction/granularity at which to work 
is the level of abstraction at which our acts of designation give us 
convenient handles. As our tools for designation improve, so do the 
handles, and so do the caps that ride up on them. Hence, with a cap 
system, the quality of our security machinery might indeed improve as an 
emergent property of our improvements in user interface design. But 
forget such hopefulness and let us move straight to grumpy skepticism. 
As a worst case, even the simple current CapDesk demonstrates that caps 
work well with the document level of coarseness/abstraction. In the 
absence of improvements in tools of designation, the default is people 
continue to work with objects at the level of granularity at which they 
are currently accustomed, and use revokers at that same level of 
granularity -- which is, incidentally, even on its worst day a better 
situation than the situation that arises when you have security that 
operates at some different level of granularity/abstraction than the 
level of natural designation, because the level of granularit of the 
security action maps naturally to what you were doing.

Will this neat rationale fail sometimes? Sure. Will it fail at times and 
in ways that the current system does not? Probably, it is sufficiently 
different so we can expect human failures, with the quite different user 
interfaces to these things, to fail at differently. Will it fail more 
often than with current systems? That is just hard to believe, because 
people will have tools better in tune with their own mental models of 
what they are doing than today's systems allow.

P.S. It occurs to me that the OLE problem is the opposite failure from 
the problem we have been arguing about up to this point. The last 
arguments we were having were about the risk that caps would result in 
giving too much authority away too easily. The OLE argument is an 
argument that caps will lead us to not give enough authority away often 
enough. It is certainly the case that a technology can simultaneously 
make it more likely that we give too much authority away, and give too 
little away, at the same time. That is exactly the problem with acls, 
and is what we are trying to escape from :-) The caps answer is, 
delegate easily through designation, and VOC to prevent bad accidents, 
thus winning on both fronts :-)

--marcs