Sandro: thank you for providing such a clear definition of rights amplification. That was very helpful.
Matt: The definitions are what the definitions are. You are making some very cogent arguments about Java generally, and also about how these ideas do [not] fit into Java, but your objection to whether certain things are "rights amplifications" are a bit like objecting that 3 is not an integer. It's perfectly okay not to care for the term because you don't like what it means, but the term means what the term means. In hindsight, perhaps it was unfortunate that I used Java as a vehicle to talk about rights amplification. I've never used Java's reflection features, so unless I stop to think about them I don't remember that they are there. In consequence, I was speaking entirely in the context of Java's "as alleged" type-restricted interfaces. It seems that in giving a Java example, I introduced a lot of confusion. Matt seems inclined to defend Java at the moment, so I'm probably going to set off a storm with this next bit, but here it goes: *From the standpoint of security design, Java doesn't suck well enough to actually suck.* Some of you may remember a company called Electric Communities. They spent about $1M proving this exhaustively during the "Original E" project, and things have gotten worse since then. In fairness, Java was never designed with object-capability security in mind. The absence is a deficiency from *our* point of view, but it just wasn't a goal. >From my perspective, the things to take away from this discussion are as follows: - Rights amplifying operations are very problematic *if* you want the ability to do o-cap security in your language. - Reflection is very problematic if you want to do enforceable encapsulation for any reason. The key word in the second point is "enforceable." There are lots of reasons to have existential type in a language (in fact, it's essential for some very simple patterns) that do *not* require us to reach the level of o-cap security. It isn't clear that o-cap security should be a goal for BitC at all. The use case for o-cap security within the language arises only if you have mutually suspicious code running within the program. In my opinion, the main place where that is likely to happen is when scripting gets into play, and there are other/better ways to handle it there. It also gets into play if you are contemplating language-based protection for operating systems, which is why *I'm* interested in this. The other issue that emerges here is the problem of reflection. Reflection is very powertul and very useful, but its current form is malignant. Let's start another thread exploring what we might do about that. Meanwhile, let's move the debate about Java to comp.lang.java.sucks. :-) shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
