5 ms·

> you wouldn't be able to put a "paste" item in a context menu I don't know about that. One approach would be for the menu invocation to accept a capability ob

by tonyg 5y ago

> you wouldn't be able to put a "paste" item in a context menu I don't know about that. One approach would be for the menu invocation to accept a capability object representing the active context's interpretations of "copy", "paste", "save" etc. (A "user agent" if you will!) The menu would then invoke methods on that object. That way, interactions triggered by the mouse would propagate the appropriate capability. Other uses of the menu would have to synthesise an object of the correct type, which they could do, but they wouldn't be able to forge access to the user's clipboard. In general, capability style thinking benefits from removing ambient authority such as a global clipboard, replacing it with an object explicitly representing the necessary authority in each context.

robertlagrant 5y ago
If you do that then why can't the program invoke methods on that object whenever it wants to?
- tonyg 5y ago
  Good question. You only pass it with an interaction event. (And you revoke the capability once the interaction is over.) Not perfect: stops background pasting without interaction tho. To do better, the only way I can think of right now is having paste only triggerable by a secure context (e.g. keyboard shortcut, as above). Any mechanism by which the user can declare "I intend to paste" in so many words without the app being able to forge it. But that needn't rule out context menu paste, I don't think, if there's a way for the secure context to unforgeably decorate the menu when it declares it wants a paste action. It's a fun thing to think about the design of. I encourage us all to try to think creatively about it rather than quickly jumping to "it can't be done".
  - tonyg 5y ago
    FWIW, for those coming across this thread later: There has been some research on these topics (of course). I asked the `cap-talk` list to jog my memory, and received pointers to the following interesting starting points: - "Design of the EROS Trusted Window System", Shapiro, Vanderburgh Northup and Chizmadia. USENIX Security 2004. https://www.usenix.org/legacy/publications/library/proceedings/sec04/tech/full_papers/shapiro/shapiro.pdf https://www.usenix.org/legacy/publications/library/proceedin... - "A Capability Based Client: The DarpaBrowser", Stiegler and Miller. Technical Report, June 2002. http://www.combex.com/papers/darpa-report/html/ http://www.combex.com/papers/darpa-report/html/ The Shapiro et al. paper discusses many of the issues brought up in this thread, along with the solution they chose for the actual working software system they had implemented.
  - robertlagrant 5y ago
    Sure, if the OS offers an "add a cut/copy/paste menu option here" as part of their native UI library (if they offer one) then that could work, and/or saying "I delegate cursor focus, cmd-x, cmd-c and cmd-v to the OS to control for clipboard access". I just didn't understand how the specific mechanism you were describing would help.

by tonyg 5y ago

robertlagrant 5y ago

If you do that then why can't the program invoke methods on that object whenever it wants to?

tonyg 5y ago
Good question. You only pass it with an interaction event. (And you revoke the capability once the interaction is over.) Not perfect: stops background pasting without interaction tho. To do better, the only way I can think of right now is having paste only triggerable by a secure context (e.g. keyboard shortcut, as above). Any mechanism by which the user can declare "I intend to paste" in so many words without the app being able to forge it. But that needn't rule out context menu paste, I don't think, if there's a way for the secure context to unforgeably decorate the menu when it declares it wants a paste action. It's a fun thing to think about the design of. I encourage us all to try to think creatively about it rather than quickly jumping to "it can't be done".
- tonyg 5y ago
  FWIW, for those coming across this thread later: There has been some research on these topics (of course). I asked the `cap-talk` list to jog my memory, and received pointers to the following interesting starting points: - "Design of the EROS Trusted Window System", Shapiro, Vanderburgh Northup and Chizmadia. USENIX Security 2004. https://www.usenix.org/legacy/publications/library/proceedings/sec04/tech/full_papers/shapiro/shapiro.pdf https://www.usenix.org/legacy/publications/library/proceedin... - "A Capability Based Client: The DarpaBrowser", Stiegler and Miller. Technical Report, June 2002. http://www.combex.com/papers/darpa-report/html/ http://www.combex.com/papers/darpa-report/html/ The Shapiro et al. paper discusses many of the issues brought up in this thread, along with the solution they chose for the actual working software system they had implemented.
- robertlagrant 5y ago
  Sure, if the OS offers an "add a cut/copy/paste menu option here" as part of their native UI library (if they offer one) then that could work, and/or saying "I delegate cursor focus, cmd-x, cmd-c and cmd-v to the OS to control for clipboard access". I just didn't understand how the specific mechanism you were describing would help.