On 07/07/2014 3:26 PM, Matt Oliveri wrote: > Alright I'll bite. Using Haskell as an imperative language with > frequent calls to unsafePerformIO would be very annoying and > unnatural. Using Java in the way I describe is not at all unnatural.
You're changing the goalposts. You said that Java's type system does not guarantee that you can't call a method if it doesn't belong to a type. In fact, the only way to attempt to call a method that doesn't belong to the type is via reflection, and contrary to what you just claimed, method invocation via reflection is quite unnatural in Java. > I'd like to end this conversation. As far as I can tell, no one has > given evidence that my way of looking at Java is unequivocally wrong. What is wrong are the specific claims that downcasting is not rights amplification, and that an object's dynamic type defines the permission set (and not the static type in scope). No other claims were disputed other than these security claims. Your claim that "downcast should not be considered rights amplification", at least in Java, is simply wrong. The definition of rights amplification is intensional: the combination of two or more authorities yields a new authority greater than can be achieved via any combination of its individual parts. For downcast, we combine an object instance of type Foo and an ambient type descriptor of type Bar <: Foo, to yield an instance of Bar which exposes more permissions than either Foo or the Bar type descriptor provide individually in the given scope. That's a clear rights amplification. Ditto for reflection. Your position on permission sets is also perfectly clear, namely that the dynamic type of a Java object defines its permission set because, like dynamically typed languages, we can invoke methods dynamically via reflection (or by downcasting) instead of being constrained to the type in scope at the time; thus, the capability patterns used in such dynamically typed languages are needed for unrestricted Java. No one disagreed with this last point. Our disagreement has been over classifying Java using capability terminology: You: in Java, objects are dynamic types which define permissions sets. Me: in Java, scoped static types define permission sets, and two rights amplification primitives are available, downcasting and reflection. Is the latter not a more precise and useful conceptualization? We know immediately that writing a class loader that forbids programs that call reflection APIs or use downcasting instructions yields a typed capability secure runtime. We also know that the presence of these rights amplification primitives are what necessitates the use of dynamically typed capability patterns. What utility does your position provide that is not captured by my position? I've already asked this, but you never answered that I can recall. Sandro _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
