2 ms·

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

by 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

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.