On Fri, Jul 4, 2014 at 11:41 PM, Matt Oliveri <[email protected]> wrote:
> I'm not convinced. Rights amplification is not as bad as undeniable > authority as far as I can see. It makes figuring out authority harder, > but it's still very systematic, and the answer isn't necessarily bad > news. > If you think about it, I think you'll conclude that ambient authority (which is what you call "undeniable authority") is the logical extreme of rights amplification gone amok. But I also think that there are two different *kinds* of rights amplification, and what you are saying is valid for one of them. The first one is hard to define rigorously. It basically amounts to giving out (or receiving) unintended and/or excessive authority because it wasn't easy enough to understand what authority you were being handed. It's discoverable in principle, but it may be easy not to notice how much authority you got, and consequently it gets harder to determine how much responsibility you need to take in guarding the references that you hold. Every place where I can invoke one interface to get a second interface (and downcast is kind of a special case of this), the potential for this kind of error creeps in. Sometimes it's the right design pattern. I don't mean to say it's not. All I'm trying to say is that *if* we are using interfaces for protection, this is an issue that requires attention on the part of the developer. The second one is much easier to describe. In PL terminology we might call it "de-encapsulating operations". These are operations that penetrate an explicitly represented abstraction boundary. An interface is an explicitly represented abstraction boundary. Where we use interfaces to implement security-enforcing encapsulations, I think it's fairly clear that we want to take great care about how those might get de-encapsulated. Obviously, I'm dragging an idea from capability systems into the PL world here in a slightly different way than has been done previously. I'm probably not capturing all of this right, and we're going to have to learn (a) do we even need this, (b) is this the right place to embed this idea, and (c) if so, what are the idioms we want to teach and talk about. I don't yet feel that I have answers to those questions. > So in > capability systems with rights amplification, it seems you should ask > about the authority of a set of capabilities. The idea being that > determining authority isn't reducible to determining the authority of > the individual capabilities (or any strict subsets of the full set) in > isolation. What's wrong with thinking about authority this way? > I'm sorry. You raised this before, and of course you are right that you want to think in terms of sets of capabilities. > It sounds like you're still thinking of downcast as rights > amplification. That's pretty frustrating. Has nothing changed...? Downcast gives you more operations to perform. Therefore it is rights amplifying. This is purely a matter of definition. It's not an ideology debate. > > I think we've talked this through at this point. > > Are you saying you don't want to discuss it anymore? I don't think > we've settled much of anything. > No no. I'm saying that I have enough to let this simmer a bit. You've convinced me that I need to consider this a bit more carefully. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
