Now - should methods of mutable types be off-limits in the future? [...] I don't think it would be acceptable for 'append' to be off-limits in this case, so the alternative is that the security machinery would somehow have to be able to distinguish mutables created by the user from those obtained from the secure environment. That would probably mean that API code would have to make some sort of security assertions about mutables they returned.
I have another alternative -- Unless I really intend to return an unprotected mutable across subsystems, most often it's a mistake. Even if security isn't an issue, it leads to wonderfully obscure bugs if a customer of my class blithely modifies my return value. (I returned it to you, after all, you thought it was yours now!) If I do want to return a dictionary for you to *read*, I could just as easily code my intention and return a read-only class that implements __getitem__. Since on occasion I might deliberately want to return an unprotected mutable value for a good reason, what would be helpful is if the security system forbid me from returning unprotected mutable values unless I explicitly say I intend to do so. I'd encourage the check to recursively descend through tuples and, if we create a standard read-only dictionary for everyone to use, through read-only dictionaries. Note such a check would be just as helpful for products written using Python Methods, or DTML, as it would be for products written in plain Python. Then the security system doesn't need to keep track of where unprotected mutables came from. Once I've said explicitly that I intend to return an unprotected mutable, I can take care to return a copy that I don't use after I've passed it on to you. Andrew