On Wed, Nov 11, 2015 at 1:50 PM, Ben Kloosterman <bkloo...@gmail.com> wrote: > http://joeduffyblog.com/2015/11/10/objects-as-secure-capabilities/ > > Some interesting comments so far ..
hmm, I didn't see any comments, guess I need to go look in the usual places for them I find the following bit particularly interesting: >>Well, what's wrong with this? >> >>It's imprecise. It relies on ambient state that is invisible to the program. >>You >>can't easily audit to see the security implications of the operation. You just >>need to know how open works. as i've somewhat stumbled over it making 'consensus gates', which is like a sealer/unsealer pair in which the unsealer is fragmented and distributed to multiple parties, meaning unsealing depends upon the logic inside the consensus gate... at first impression this seems ok because holding a fragment of an unsealer is holding some piece of potential authority, but contains a risk of confusion when looking at the authority contained within a domain contrasted with the authority given by the logic within the domain. my thoughts have been to split invocations/type signatures between messages which provide authority to properties of objects and being compiler generated will return some capability under normal and non-proxied behavior, and those which suffer from some variation of the halting problem making it undecidable whether they will pass on some authority... or disallowing such gates all together... I say non-proxied because this requires a different guarantee that 'allegedType' can't give and seems to require tying in with the whole factory branding mechanism _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
