16 Matching Annotations
  1. May 2019
    1. The individual does not use this information and this processing to grapple directly with the sort of complex situation in which we seek to give him help. He uses his innate capabilities in a rather more indirect fashion, since the situation is generally too complex to yield directly to his motor actions, and always too complex to yield comprehensions and solutions from direct sensory inspection and use of basic cognitive capabilities.

      The mention here of "innate capabilities" and the importance to yielding motor actions toward complex challenges, is noted. A question arises, regarding "basic cognitive capabilities" and their role in the process?

  2. Sep 2018
  3. Mar 2018
    1. Lucius Gregory Meredith, Mike Stay, and Sophia Drossopoulou. Policy as types. CoRR, 2013. URL: http://arxiv.org/abs/1307.7766.

      I think I have my head around this one now.

  4. Sep 2017
    1. extremely cool, but...

      comparing with tahoe-lafs:

      clearly separates writecap from readcap, but... does it grok readcap as separate from idcap?

      client-side encryption?

      n-of-k erasure encoding?

  5. Aug 2017
    1. Processes can register servers on the Switchboard, to which clients can connect.

      reminds me of the dbus clean-up

  6. Jul 2017
  7. Mar 2017
  8. Aug 2015
    1. In order to avoid the confused deputy problem, asubject must be careful to maintain the associationbetween each authority and its intended purpose. Using the key analogy, one could imagine immediatelyattaching a label to each key upon receiving it, wherethe label describes the purpose for which the key is tobe used. In order to know the purpose for a key, thesubject must understand the context in which the key is received; for example, labelling is not possible if keysmagically appear on the key ring without the subject’sknowledge.
    2. Even if one can distinguish the keys, decidingto try all available keys puts one at risk of becoming aconfused deputy.
    3. We would argue that the “true” capability model is the object-capability model, because all known major capability systems take the object-based approach (forexamples, see [1, 4, 9, 11, 16, 17, 19, 21]). In all ofthese systems, a capability is an object reference–not something that behaves like a key or ticket in the realworld. Definitive books on capability-based systems[6, 16] also describe these systems from the object-capability perspective, and explicitly characterize themas “object-based”.
    4. The claim that capability systemsin general cannotenforce the *-Property appears to be based on themisunderstanding that capabilities and data are notdistinguishable.
    5. Theonly capability Bob holds to a lower level is a readcapability, so the *-Property is enforced. The onlycapability Alice holds to a higher level is a writecapability, so the Simple Security Property is enforced

      This paragraph would be clearer if the capabilities were written out fully:

      The only capability Bob holds to a lower level is a "read data" capability, so the *-Property is enforced. The only capability Alice holds to a higher level is a "write data" capability, so the Simple Security Property is enforced.

      Maybe. But it still seems confused. As though the properties are in the wrong sentences.

      Nonetheless, both properties are enforced.

    6. we examine three different models thathave been used to describe capabilities, and define a set of seven security properties that capture the distinctions among them