markm: That's very well put. I think we can use that. Thanks!
     rwithers12: please do!
 markm: Funny you should mention that. We just had some interesting victories for distributed debugging of E code. I hope to explain more about this soon...
     markm: But first some history.
     rwithers12: I like the causality pane. A great idea.
 markm: From earlier correspondence I thought there was, but don't worry about it. I hope to drop Java serialization as well.
     rwithers12: Yes, I thought so too, but it was only an import/export analyzer, not a serializer.
 markm: Have you looked at Tyler's Doc and how Tyler's WOMP uses it for serialization?
     tyler: If you do decide to use the Waterken Object Serialization
     rwithers12: we are well into the issues, now. Even if VatTP becomes outdated, I'll at least have the experience.
 markm: It is compatible with all deployed smart contracting systems! Ha, take that!
     rwithers12: :)
 markm: I have no idea. If it's a serious suggestion, I'll try to take a look at it.
     rwithers12: it is squeak specific.
 markm: We definitely need to get the negotiation in there. This negotiation should itself be textual, so binary-impaired participants can still play.
     rwithers12: While you are thinking about this, should we do compression negotiation too?
 markm: http://www.erights.org/symbolic/overview.html and http://www.erights.org/symbolic/terml/terml-spec.html are my early drafts of
     markm: These remind me of another very preliminary draft I never announced but should have:
     markm: As the red text at the top explains, I already know this essay is broken in some ways.
         hal: I find one thing confusing about the question of whether capabilities and ACLs are two different ways of looking at an accessibility matrix.
         hal: Now it may still be true that in practice, capability systems have far finer granularity even than my Linux system with its 20-odd accounts.
             marcs: I think you are right that the explication in the paper needs to be clarified,
             markm: If your /etc/passwd file is being automatically extended in ways you don't feel a need to review,
         tyler: I think your paper could do a better job of taking apart Lampson's "Protection" paper.
             markm: Tyler, I think you have the start of an excellent paper here, different and complementary to mine.
                 ping: Hi Mark,
         hal: Both essays claim that while this equivalence might be true in a trivial mathematical sense,
             markm: Actually, the point of my essay is to claim that this is one of a whole long list of ways in which these systems are not equivalent.
             markm: I was trying to say two things at once, so perhaps I said both badly.
         hal: Anyway, I don't even know what most of these accounts are.
             markm: I am puzzled by the appearance of new accounts. Where do they come from and how did you come to believe they are probably legitimate?
         hal: Clearly most of these names are associated with programs and processes.
             markm: By "expanded" are you referring to the automated expansion of the ACL of your system,
         hal: So the point may still be valid that capabilities lend themselves to an architecture with extremely fine-grained granularity of access,
             markm: Once this discussion settles some, I will clarify the paper. Thanks!
         tyler: There are a number of other really bad errors in the Lampson model and in the Lampson paper.
             markm: It took me a long time to accept that the scientific community process can be this broken, but, when viewed at the granularity of decades,
             markm: I do believe our extended community is about to put this particular bogosity to rest for good (regarding science, not engineering).
                 alan_karp: A recent quote in Scientific American says it nicely. "Science makes progress one funeral at a time."
         hal: (Hopefully I haven't opened my system up to attack by publishing this; if so please let me know,
             Radix42: Well, you've revealed which user accounts have valid shells
         tyler: The main point of confusion is the belief that Lampson's access matrix models both the ACL and capability systems.
             daw: Is it a misunderstanding? Or is this just a disagreement over the definitions of the words?
                 tyler: It is a misunderstanding. In the "Protection" paper, Lampson uses the term "C-list" to refer to something that is not a C-list.
             daw: Therefore, my conclusion is that it would be more effective to pick a new term for E-style capabilities,
                 ping: Other people have further diluted the meaning of the word "capability" by coining "POSIX capabilities",
                 tyler: As MarkM has often and pointedly said, there is nothing new about the security principles behind E.
             daw: There are two kinds of mechanisms that might have claim to the name capabilities:
                 tyler: I am not calling the Lampson mechanism a C-list. Lampson is. I am saying that the Lampson mechansim is not a C-list.
                     markm: Absolutely. I would be horrified if they become known as "E-style capabilities".
                     markm: However, if a good excuse for a distinction could be found, I think "<adjective>-capability", for some appropriate adjective,
                         shap: I disagree. If you are going to pick a new term, think about it as a problem in differentiable brand identification.
                             markm: This line of reasoning is too far outside my expertise for me to reason about competently.
                     markm: Reaching further back in our history,
                         tyler: I want to think about my reply more before sending it, but I have one factual question now.
                         tyler: Given this mechanism, you can implement all the functionality of the Granovetter diagram.
                             markm: I hadn't remembered this feature of Dennis and Van Horn.
                                 tyler: I took this information from the Henry M. Levy book on capabilities.
                                 shap: Nor had I. I also remember the universally cited paper as dealing primarily with memory references.
                                 tyler: Are you just moving the line somewhere else or are you erasing the line? Are you still proposing a name change for capabilities?
                                     markm: I was trying to move the line.
                                 tyler: The Levy book credits the Dennis and Van Horn system with the coining of the term "capability".
                                     markm: If there are no C-lists-as-sets capability systems
                                         daw: At risk of prolonging this longer than necessary, how about "true capabilities" vs.
                                             tyler: I think we now have more than enough evidence on the table to prove that there is no such thing as a "Lampson-style capability".
                                                 shap: Guys, isn't it striking that this is the only place where the "what is a capability?" ever gets discussed?
                                                     patrickdlogan: As a newbie enthusiast lurker, yes, this observation struck me.
                                                 daw: Of course there is such a thing as a "Lampson-style capability". I think you mean that noone builds systems this way. Maybe so, but so what?
                                                     tyler: No, I meant that noone builds systems this way and noone ever even proposed building systems this way.
                                                     tyler: Changing names makes it much more difficult to achieve this "Ah-hah".
                                                         marcs: The claim that introducing a distinguishing adjective makes it more difficult to achieve the "Ah-hah" is as untested as my hope that introducing the
                                                             tyler: How can I explain that Lampson simply misunderstood the term "capability" if you go and define his use to be correct?
                                                                 daw: You misunderstand the proposal. The proposal never was to define the bare term "capability" to refer to the kind of system Lampson described.
                                                                     tyler: My impression is that making these distinctions surrenders the word "capability" to mean whatever it is that people currently
                                                                 marcs: This is not unlike the problem the quantum mechanics folks had with physics.
                                                         marcs: The most reliable way of getting people to have the "Ah-hah" experience I have yet seen is
                                                             alan_karp: I've seen the demo, and I believe it is a dramatic demonstration of the benefits of POLA. However, the distinction between ambient and object capabilities is not as clear. That's probably as it should be. If the authorities were to be more visible, the user interface would appear to be too awkward to gain acceptance.
                                                                 marcs: benefits of POLA. However, the distinction between ambient and object capabilities is not as clear. That's probably as it should be.
                                                     tyler: Not many real arguments have been presented for renaming. I've tried to refute those I could find.
                                                         marcs: I'm not expecting a magic bullet. I'm just hoping for a little assist in overcoming an existing, far-too-well-proven, impediment.
                                                     tyler: I suggest that Marc Stiegler list the arguments in favour of renaming and provide evidence that each is valid.
                                                         marcs: Providing evidence requires test marketing. That is what I propose to do.
                                                 daw: Oh dear. I think somehow I've failed again to convey my point. I'm a little depressed by this, but since I'm stubborn, may I try again?
                                                     tyler: I think I could have done a better job of drawing the link between your last email and my thoughts on it.
                                                         daw: Thanks for the encouragement. By the way, I'm definitely not giving up on the conversation.
                                                 daw: Those of us here on this group have a concept of the "wrong" way to do capabilities, namely, make them ambient.
                                                     markm: Note that earlier, you yourself wrote:
                                                 tyler: David criticized the first sentence without acknowledging the second.
                                             marcs: Actually, I think this discussion does need to be prolonged a little longer, because the current situation is, for me personally, a disaster.
                                             tyler: Unless there is an actual thing to be referred to by the name "Lampson-style capability", there is no sense in the name.
                                                 daw: This is plainly wrong. If we want to criticize it, it helps to name it. What we can't name, we can't critique.
                                             marcs: So,
                                                 daw: Thank you, Marc, for your very encouraging note.
                                                 tribble: I think I first started using the term "ambient authority" system when Netscape was bandying about their bogus "capability" security model.
                                             marcs: 1. Stop trying to market capabilities.
                                                 tyler: Following through with your argument, quantum physics would have won earlier if only it had changed its name to "packet physics".
                                             marcs: 2. Invent a new word for what we have, acknowledging that "capability" has been as badly distorted as the term "hacker".
                                                 tyler: The problem is not one of distortion, but of a lack of understanding.
                                                     marcs: This sounds like distortion to me. A view of a system that does not see the full value of the system pretty much fits my definition of a distorted view.
                                                 tyler: You are injuring the history for no actual advantage.
                                                     marcs: You sound as if the history has not already been injured to the point of being scarred beyond recognition.
                             alan_karp: As described in Dennis and van Horn, a capability contains an identifier for a segment (resource) and a set of rights. A c-list is a set of handles to these capabilities. The permissions are explicitly listed in the capability and are interpreted on access to the resource. My understanding of an E-capability is that it is an identifier to a facet of a resource, identical to an object handle. The permissions are implicit in the facet being identified. No interpetation of rights is needed; either the facet has the method, or it doesn't. That's why in my paper I list E-capabilities as different from what I call traditional capabilities.
                                 tyler: I'll have to re-read, but I believe these permissions are for memory segments, not for protected procedures.
                                     alan_karp: Certainly, Dennis and Van Horn only describe memory segments, but what they say appears to be applicable to resources (objects) in general. I also agree that you can think of the permissions as equivalent to the method names, but it is clear to me that they do not.
                                 tyler: This is the same for protected procedure capabilities in the Dennis & Van Horn system.
                                     alan_karp: To me the difference is the explicit listing of permission in the DVH capabilities and implicit nature of the permissions associated with an E facet.
                                 tyler: In the case of protected procedure capabilities, the capabilities are remarkably similar to E capabilities,
                                     alan_karp: The first case, but not the second. Could DVH have a separate vtable for each capability? Yes. Did they? I don't believe so. The essential difference to me is the fact an E capability is a reference to a facet that has vtable with a subset of the methods available on a resource. In DVH a capability is a piece of data that contains a reference to a resource and a list of permissions.
                                 tyler: Thank you very much for the URL for the Dennis & Van Horn paper.
                                     alan_karp: Glad to be of help.
             daw: I suspect you would like to reserve the term "capabilities" for E-style capabilities only.
                 tyler: It is amazing the amount of damage that one confused scientist can cause.
                 shap: I'm not sure that the disconnect you surmise actually exists.
                 shap: First, the Lampson defintion does combine designation and authority.
                     alan_karp: No disagreement here. Do you have a better name? My paper "Using Split Capabilities for Access Control" is scheduled for the next issue of IEEE Software. I'm just getting ready to fax the changes to the galley proofs to the editor, so this is my last chance to find a better name before the concrete sets.
                     alan_karp: _________________________ Alan Karp
                         shap: I think this is a fine idea.
                 shap: A C-list isn't a capability. It is a collection of capabilities.
                     markm: This seems like a good excuse for a distinction. A C-lists-as-set system is necessarily vulnerable to confused deputy.
                         tyler: What are the names of these "C-lists-as-sets" systems? Were any of them in existence before Lampson's 1971 "Protection" paper?
                             shap: The very earliest capability systems were segment-like systems. All required selectors.
                                 markm: Your treatment of C-lists-as-sets was clearly not in order to propose that any actual system operate in this way.
                             shap: The POSIX capabilties API is definitely set based, as are Netscape's "Java Capabilities". I'm not clear about split capabilities.
                                 markm: We've all repeatedly agreed that Netscape "capabilities" and Posix "capabilities" aren't.
                         tyler: I've only seen "C-list" as indexed list. I assume you are calling this a "C-list-as-maps".
                             shap: Yes.
                     markm: As I mentioned earlier, lambda calculus demands C-lists-as-maps
                     markm: Even if all actual capability systems are lambda-capability systems, since most formal models of capabilities
                         shap: These models do not claim to faithfully model real systems, nor do they claim to faithfully model capabilities.
                         shap: For example, the EROS confinement verification says explicitly that the real system does not use sets,
                             markm: So far, we're in complete agreement, as should be clear from the email you're quoting.
                         shap: Picking a new name won't help. It will simply lead to the publication of appropriately simplified models of lambda capabilities too.
                             markm: So long as the models are not mistaken for complete descriptions of the capability-ness of the systems themselves,
                             markm: (Despite the fact that there wasn't anything wrong that I know of with Lampson's own capability OS design, CAL-TSS,
                                 tyler: My only source of information on CAL-TSS is the summary in Levy's capability book.
                                     markm: See reference 15 at http://research.microsoft.com/lampson/Publications.html
                                         tyler: Thank you. If anyone has lines on the others, please speak up!
                                         norm: I have not kept up with the list the last few days but I do have something to report.
                                     shap: The Chicago Magic Number machine and the CAP system, both of which predate CAL/TSS, both had protected procedures.
                                 tyler: Where and when did Norm's sense come from? Has Norm already written something about this?
                                     markm: Norm?
                                 tyler: What else do you know about the history that makes you concur?
                                     markm: Mostly my sense that Lampson is currently dismissive of capabilities.
                                 tyler: Is there anything in "Protection", or elsewhere, to suggest that Lampson intentionally made an inaccurate model?
                                     markm: No, I never imagined the inaccuracies were intentional, and there's no need to question anyone's motives.
                                         tyler: I meant "intentional" in the same way that Jonathan's SW model is intentionally innacurate.
                                             markm: Ah, now I understand the question. But I wouldn't say that SW is "inaccurate".
                                                 vze2729k: I believe that the most precise characterization would be "accurate, but incomplete".
                                                 shap: In modeling terms, the statement you want is "so long as the model is strictly more powerful than the real system".
                                                     tyler: ...
                                                 shap: The lampson model is not flawed in the sense that it is strictly more powerful than a real capability system.
                                                     tyler: Wow, this is really bad jargon. The interpretation of the sentence in plain English is completely misleading.
                                                         norm: I agree it is bad jargon. I think the fact of the mater is merely that security often stems from what you can't do, thus weaker may be securer.
                                                             zooko: Yes, and having a more secure system allows you to do more things safely.
                                                     tyler: Can you suggest a textbook that defines this modeling jargon?
                                                         shap: I think it's just really unfamiliar jargon. When you see the definition it will make perfect sense.
                                                             norm: Let me try to say something with minimal jargon.
                                                             tyler: Thanks for the definition. I still think it is an unfortunate choice of words.
                                                         shap: The basic Lampson access matrix based formalism does support confinement,
                                                             tyler: The main Lampson model, presented in the "Protection" paper, explicitly *does not* support confinement. See rules b and c.
                                                                 shap: What I meant to say is that the access matrix is a perfectly fine way to talk about the state graph and its evolution.
                                                             tyler: In the text, Lampson suggests a possible technique for preventing "de jure" transfer of authority.
                                                                 shap: The "do not copy" bit was a mistake that Norm has adequately addressed elsewhere.
                                                             tyler: Nowhere does Lampson address "de facto" transfer of authority.
                                                                 shap: It is true that the paper does not address de facto transfer.
                                                                 shap: The access matrix model is simply a way of writing down a graph that captures the instantaneous access rights of a system.
                                                         shap: I caution, however, that you seem to still be insisting on conflating some things and that this is getting in your way.
                                                             tyler: One of the purposes of this email thread is to find any holes or inadequacies in the argument I have presented.
                                                                 shap: I don't have time to do extended hermeneutics on the last month of exchanges.
                                                             tyler: I have not suggested anything like this.
                                                             tyler: I am not sure what you are saying here.
                                                             tyler: Lampson is the one aiming for a universal verification model. This is our main issue with his paper.
                                                                 shap: I don't read it that way,
                                                                 shap: Lampson attempts to prove no such thing. Kindly point me to the place in the text where any such "proof" is introduced.
                                                             tyler: "A deputy is said to be 'confused' if processing of a request makes use of authority that the deputy did not intend to apply to
                                                                 shap: That seems like a good informal definition. Formalizing it is quite hard. The difficulty is that you need to define "intends".
                                                             tyler: In a capability system, it is only possible to form a request by selecting the permissions that the request should use.
                                                                 shap: That is greatly overstated. Designation provides the possibility of non-confusion. Confusion results from misuse.
                                                                     frantz: I think this statement overstates also. What is stated as "possibility" should be "high probability".
                                                             tyler: Confusion is only a consequence of the fact that an ACL model manipulates permissions in aggregate rather than individually.
                                                                 shap: It's not clear here what you mean by "the ACL model".
                                                             tyler: (Note: this argument applies only to the protection primitives. It is possible to build an ACL system using a capability system.
                                                                 frantz: I am not sure statement this is necessarily true.
                                                         shap: The SW and DimTake models were developed to analyze a particular set of information and authority flow properties.
                                                             tyler: I agree, and this is why I am criticizing the Lampson model and not the SW model.
                                                         shap: I think much the same confusion is happening in the discussion here about the Lampson paper.
                                                             tyler: The problem is that Lampson never restricts the applicability of his model.
                                                             tyler: Exactly which problems the paper was trying to solve is at issue.
                                                             tyler: This is patently false and inflammatory. Some of us have been critical of the "Protection" paper.
                                                             tyler: There has been nothing disrespectful in the arguments presented.
                                                             tyler: Then there should be no shame when mistakes are pointed out.
                                                                 shap: That depends on how one points them out. Analysis and discussion is appropriate. Anal-retentive hermeneutics crosses a line at some point.
                                                             tyler: I find it very ironic that, in "Protection",
                                                                 shap: Read the preceding paragraph again. Lampson is not taking a position.
                                                         shap: In short,
                                                             tyler: I don't see any evidence of this in the email archives. I see some explicit evidence to the contrary.
                                             markm: Rather, I would say that SW is an accurate abstraction of EROS, even though this abstraction describes an ambient authority system.
                                                 vze2729k: As a general observation,
                                                     shap: I've said this before, but I don't think I've said it clearly enough.
                         shap: I invite you to revise the verification proof in either our paper or the earlier TR to re-express the verification in terms of indexed arrays
                             markm: Again, as you'll see in the email you quote,
                     markm: If you yourself would even consider admitting C-lists-as-sets systems into the category "capability system",
                 shap: 1.
                     ben: Surely this isn't a possible scenario for the kinds of capabilities EROS or E have?
                         markm: Absolutely not. E, EROS, and virtually all actual capability systems are what Jonathan calls C-lists-as-maps.
                         shap: Indeed not.
             daw: One could have a battle royale over who gets to choose the definition of the word "capability". However, I'm not sure that this is productive.
                 tyler: There are a number of operating systems, predating the Lampson paper, that implemented capabilities.
             daw: (Yes, I know it probably pains you to give up the word "capabilities".
                 tyler: There's more than just a word at stake here.
     rwithers12: they are on the stack.
 markm: Thanks! Frankly, I don't know how to get to auditors from Squeak without some rather violent changes, but it's certainly worth a try!
     rwithers12: hmmm....even more interesting.
 daw: I don't know enough about the history to have a position on the history.
     tyler: Over the course of this email discussion,
         daw: Fantastic! I look forward to the result. Let me know if I can help by commenting on drafts or somesuch.
     tyler: As MarcS has pointed out, Butler Lampson has a god-like position within the security community.
         daw: Maybe so, but speaking personally, when it comes to science, I prefer to avoid putting too much faith in god-figures.
             shap: That's only because pigs in a poke are traif.
         daw: This may be true,
         daw: All in all, I'm not sure I would have picked up the key ideas of this community without the personal nudging,
             shap: I agree with all of your points, and I have suggested several times to MarkM that he, I, and perhaps Jonathan Rees
                 marcs: Jonathan, who has opposed all this naming distinction stuff, used the "lambda capability" term, and it was so natural,
         daw: - the capability community has a jargon of its own that took me a while to pick up
             frantz: Perhaps having been active in the capability community for on the order of 30 years, I'm the last one to try to grok the problems of newcomers,
                 daw: I went through the exercise of trying to write down the worst offendors, and in retrospect it's probably not quite as bad as I made it out to be,
             frantz: Cheers - Bill
                 marcs: Looks like this is another vote in favor of "object capability".
     tyler: As you've said, in actions and in words, you are friendly to the capability view.
         daw: I guess I'm being careful in my wording for two separate reasons:
     tyler: All I am looking for is an evaluation on the evidence presented to date. What part of the evidence do you find lacking?
         daw: Well, I guess I see two separate gaps in the current literature:
     tyler: I would like to address the other content in your last message; however,
         daw: Shoot away! I didn't mean to withdraw from the entire conversation.
 daw: Well, speaking as an outsider, my sense is that E has been doing a good job of building running code,
 daw: Well, I'm not sure this is a workable approach on its own. This issue requires more than a footnote to do justice to. It needs a whole paper.
 daw: Ok, fair enough. This is a different goal from convincing the security community.
 marcs: I would agree that it was impetuous if I thought I was renaming the field in 4 days. There are a couple of ways in which this is not true.
     markm: I liked your message a lot, but I take exception to...
     tyler: Maybe it would help me undertand this if I could get a point of reference.
         shap: Two come to mind. Neither is a capability system in the sense that the literature has used the term.
     tyler: I asked Jonathan this same question in different wording a few days ago.
         shap: Concur.
 marcs: Secondly, just because I start using a bit of jargon (oh no! more jargon!
     tyler: I am glad to hear that this is just "test marketing". I am much happier with this.
     tyler: Do you have any evidence that a group has written you off because they thought capabilities are the same as ACLs?
         daw: My fear is that the majority of the security community might have this reaction. Do you consider this unlikely?
             tyler: Fear is a useful thing, but we cannot act on fear alone.
             shap: This has not been my experience.
             tyler: Personally, I have never had difficulty communicating that my software is very unlike an ACL design.
                 alan_karp: I've had the same experience. Everyone gets it. Everyone except the security people I talk to, that is. Their brains seem to shut down as soon as they hear the word "capability". Do you think it's some form of post-hypnotic suggestion?
 marcs: I don't expect the name to be particularly magic. I expect it to give me an assist in keeping people's attention.
 marcs: We agree the goal is to dismiss it.
 tyler: It's amazing how quickly a conversation on this list can turn.
     shap: With respect to the participants, I will not participate in any renaming of the "capability" concept,
 tyler: The main point of this email will be to convince people to slow down and carefully consider their reasoning.
     marcs: I would agree that it was impetuous if I thought I was renaming the field in 4 days. There are a couple of ways in which this is not true.
         markm: I liked your message a lot, but I take exception to...
         tyler: Maybe it would help me undertand this if I could get a point of reference.
             shap: Two come to mind. Neither is a capability system in the sense that the literature has used the term.
         tyler: I asked Jonathan this same question in different wording a few days ago.
             shap: Concur.
     marcs: Secondly, just because I start using a bit of jargon (oh no! more jargon!
         tyler: I am glad to hear that this is just "test marketing". I am much happier with this.
         tyler: Do you have any evidence that a group has written you off because they thought capabilities are the same as ACLs?
             daw: My fear is that the majority of the security community might have this reaction. Do you consider this unlikely?
                 tyler: Fear is a useful thing, but we cannot act on fear alone.
                 shap: This has not been my experience.
                 tyler: Personally, I have never had difficulty communicating that my software is very unlike an ACL design.
                     alan_karp: I've had the same experience. Everyone gets it. Everyone except the security people I talk to, that is. Their brains seem to shut down as soon as they hear the word "capability". Do you think it's some form of post-hypnotic suggestion?
 tyler: Marc, if you want to rename the field of capability security, you must bear a burden of proof.
     daw: Just to be clear:
     marcs: I don't expect the name to be particularly magic. I expect it to give me an assist in keeping people's attention.
 tyler: This misses the point. We are not seeking to criticize the straw man. We are seeking to dismiss it.
     marcs: We agree the goal is to dismiss it.
 ping: I'm really excited by your myth-demolishing article and the discussion that's going on here.
     markm: Thanks.
     markm: That would be wonderful! I'd love to co-author this with you as a real paper. Though we already have a backlog -- the auditor paper.
         ping: Good point. I think the capability myth paper is probably more important, but i don't want to forget the auditor stuff.
     markm: How about after that?
         ping: The next semester doesn't start till Jan 14, so i ought to have some time over the holidays.
 ping: Note that the Usenix Security 2003 deadline is January 27. This might be worth a shot.
     markm: I don't know how much time I'll have before then, but it's possible.
 norm: Many in the military security community are unaware of arguments of the second form.
     shap: This is very well said.
 tyler: This would still be useful.
     shap: I agree, but I am unaware of a suitable textbook. This stuff is a bit afield for me, and most of it isn't taught from textbooks in any case.
         daw: No clue. Sorry; I've never done any of this modelling stuff, so if there was a good textbook, I probably wouldn't know of it, unfortunately.
             markm: At this point, I'm willing to believe that this use of the world "stronger" is obscure, in addition to being a rhetorical disaster.
                 brett: Perhaps "academic" in place of obscure?
 shap: The Protection paper was written in 1971. Butler was 28 years old.
     markm: confuses the issue yet again.
         shap: First, let me say that I agree in substance with all of what MarkM wrote. Then let me explain why I added the bit above to my earlier note.
         shap: When we read papers, we seek to extract meaning.
             chris: I think you're misinterpreting the word "hermeneutics".
             chris: Chris
                 shap: Chris:
     markm: I am interested in understand and explaining how the world got into its current screwed up state on computer security,
         tyler: On slashdot today:
         tyler: http://www.newscientist.com/news/news.jsp?id=ns99993168
             marick: The methodology described seems bogus. (But of course, I haven't read the original paper...) I talked to my wife about it.
 markm: First, I wholeheartedly agree with Tyler on the facts:
     tyler: ...
 tyler: You hold a position of respect within the security community. I think it would be useful for you to take a position on this issue.
     daw: I don't know enough about the history to have a position on the history.
         tyler: Over the course of this email discussion,
             daw: Fantastic! I look forward to the result. Let me know if I can help by commenting on drafts or somesuch.
         tyler: As MarcS has pointed out, Butler Lampson has a god-like position within the security community.
             daw: Maybe so, but speaking personally, when it comes to science, I prefer to avoid putting too much faith in god-figures.
                 shap: That's only because pigs in a poke are traif.
             daw: This may be true,
             daw: All in all, I'm not sure I would have picked up the key ideas of this community without the personal nudging,
                 shap: I agree with all of your points, and I have suggested several times to MarkM that he, I, and perhaps Jonathan Rees
                     marcs: Jonathan, who has opposed all this naming distinction stuff, used the "lambda capability" term, and it was so natural,
             daw: - the capability community has a jargon of its own that took me a while to pick up
                 frantz: Perhaps having been active in the capability community for on the order of 30 years, I'm the last one to try to grok the problems of newcomers,
                     daw: I went through the exercise of trying to write down the worst offendors, and in retrospect it's probably not quite as bad as I made it out to be,
                 frantz: Cheers - Bill
                     marcs: Looks like this is another vote in favor of "object capability".
         tyler: As you've said, in actions and in words, you are friendly to the capability view.
             daw: I guess I'm being careful in my wording for two separate reasons:
         tyler: All I am looking for is an evaluation on the evidence presented to date. What part of the evidence do you find lacking?
             daw: Well, I guess I see two separate gaps in the current literature:
         tyler: I would like to address the other content in your last message; however,
             daw: Shoot away! I didn't mean to withdraw from the entire conversation.
 tyler: I see a third strategy: running code and direct criticism.
     daw: Well, speaking as an outsider, my sense is that E has been doing a good job of building running code,
 tyler: Given that there has been 30 years of "bogosity" surrounding capabilities,
     alan_karp: I claim to be the first to follow Tyler's excellent suggestion. IEEE Software sent me the galley proofs for my split capabilities paper right in the middle of this flurry of emails on the subject. The paper describes the access matrix (which I think I transposed) and the row/column compression. I got the editor to let me insert the sentence "Despite the apparent symmetry, ACLs are not equivalent to CLs." with a reference to "Demolished". That's the best I could do so late in the process.
         tyler: Wow, the scientific process in action right before our very eyes. This is great.
     alan_karp: Tyler, you need to write your paper on the subject, so we have a solid piece of work to cite.
         tyler: Thank you for the encouragement. I will write a paper. I am not sure what to do with it, but I'll write it.
     daw: Well, I'm not sure this is a workable approach on its own. This issue requires more than a footnote to do justice to. It needs a whole paper.
 tyler: The goal is to get capabilities deployed.
     daw: Ok, fair enough. This is a different goal from convincing the security community.
 markm: I really really wish we had more time to work together. Every time we do, magic happens.
     ping: I'm sorry i don't have time for a more detailed reply, but i just want you to know that i share this sentiment.
 marcs: There is a real risk that "lambda" as an adjective would cause Silicon Valley VCs to label it a "science project". This is fatal in the VC community.
     tribble: That was one of many problems with the term,
 marcs: "ambient-authority capability system".
     tribble: Note that this does not define terms for the building blocks of these two systems because they can't be clearly distinguished,
 markm: So the problem isn't the models. It's the "modelling blindness" that often follows exposure to a model.
     shap: Now that I've seen this (I'm playing catch-up), I withdraw my earlier suggestion that the issue of modeling blindness isn't understood.
 tribble: I'm going to attempt to respond to Tyler's messages by expanding on this message,
     shap: Dean makes good points.
 tribble: In a previous email, I gave examples of where people had started from E-like foundations, and built ambient authority systems.
     alan_karp: I don't believe that Lampson discredited capabilities, nor do I think that was his intent.
 shap: "... MumbleSoft is an "ambient authority" system.
     frantz: And then go on to say that, for good engineering reasons, in designated authority systems,
         shap: Depending on where it comes up in the paper, this would indeed be a logical thing to say next.