On Fri, Aug 12, 2011 at 2:44 AM, BGB <[email protected]> wrote: > but, whether or not they use it, or care that it exists, is irrelevant... >
Then so is the language. > > but, anyways, FWIW, I am myself a part of the audience of people who would > use my language, so I am free to design it how I want it designed, which > happens to largely coincide with common practices. > A language is a very large investment, as you are aware. You say 'FWIW' (for what it's worth), but how much is your language worth, really? How much time and effort have you wasted on your language that would have been better spent maintaining a project in an existing language? > but, security checks seem like less up-front effort to bolt on to the VM... > The investment is about the same. > it is not clear that users can so easily ignore the existence of a > capability-oriented system. > Capability based security is quite transparent to most users. To those unaware of the security implications, it just looks like a very well designed API - one suitable for concurrent or distributed computing or testing, or flexible composition (e.g. ability to wrap access to the 'console', or have different 'consoles' for different libraries). > > also, the toplevel is very convinient when entering code interactively from > the console, or for use with "target_eval" entities in my 3D engine (when > triggered by something, they evaluate an expression), ... > A toplevel, or other forms of dynamic scope, is not incompatible with capabilities, so long as you can re-assign it for different scopes and threads. It is incompatible with secure interaction design, but that's a separate issue. > > my own imagined methodology was likely to make use of program signatures > (file hashes for the programs' image file), with user confirmation as to > whether or not they want to give certain rights to an app. this would be > because it is a little harder to forge a file hash than it is to capture > things like "magic keys" or "passphrases". > That sounds complicated, and I doubt your users will benefit from it. > > well, it works though, and a lot of people still use Windows... > Pushing blame to users is not effective for security. People suffer malware on a regular basis. IT administrators feel the need to strip a user's rights to their machines, which really chafes for programmers. People feel need to bloat their systems with anti-virus software and computer 'defenders'. Whether 'it works' depends on your goals: are you actually interested in security? or are you just trying to avoid blame? A lot of people still use Windows, but only a fool would mistake a popularity argument for a security argument. > object is not writable: why?... because we don't have write access... > otherwise, one would need to use a "readonly" modifier or similar, but this > would apply to everyone, rather than be like "well, I can use this > read/write, but everyone else gets it as read-only". > The capability approach to this would be to create a separate readonly object: var myObjReadOnly = WriteBarrier(myObj) Now, everyone who has access to 'myObj' can still write it, and everyone who as access to 'myObjReadOnly' can only read it. Potentially, the WriteBarrier could also apply to all objects returned from method calls or accessors - this is a 'membrane' pattern. WriteBarrier doesn't need to be special. It can be implemented with a much more generic feature that allows developers to override the 'getter' and 'setter' functions for an object.
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
