Max - Replies to your latest comments below:
> Thanks for your patience. Reading Ihor's message I had an impression that > Captee is enough to pass org-protocol URLs to emacs. I was not aware that it > is just share target implementation and it needs another glue application to > pass data to emacs server. If so, I see why Captee is missed in the updated > text (mentioning it still might be helpful since I am unaware of other > articles discussing capture from other apps). Will take that guidance. > >> Among the motivations for writing Scrim was that all the guidance for >> macOS users on WORG related to setting up a scheme handler for Org >> Protocol was obsolete. > > Certainly Worg page should be rewritten. > > Am I to understand that expectations of Apple is that Emacs application > should be published with implementation of share target and either universal > links (deep links in Android parlance if I do not confuse features) or custom > URL scheme? I am realizing that most variants of Emacs for macOS will not do > it so 3rt party helpers are unavoidable. If I understand your question correctly, then the answer is yes. macOS sandboxing (or in Apple parlance, hardened runtime) shifts emphasis to using custom URL schemes for simple message passing between different apps. (side note: Apple Universal links are a different implementation that achieves the same end, but using only HTTP instead of a custom URL scheme). Implicit in Apple app architecture is that an app (in this case Emacs) would register their custom URL schemes with the OS. As Emacs Core is reluctant to do this for a non-free OS, it is left up to 3rd party actors to implement this behavior, either natively like the Yamamoto fork, or by proxy as I have done with Scrim. > > Thanks for explanation. I am surprised that a sandboxed app may access this > shared file with a secret. A macOS hardened runtime app can access files outside its sandbox via the macOS file browser which is considered a trusted actor that is not part of the app. The file access can then be annotated (in Apple parlance, “security bookmarked”) as a permitted file for access by the app on subsequent runs. Note that such apps must also be configured with the entitlement to do so. > > Is it restriction namely for operations with sockets or path where Emacs > creates its socket is inaccessible? From my point of view it may be expected > that running external binary (emacsclient) is prohibited, but I am unsure why > a custom communication channel (perhaps with custom permission) may be > harmful. Anyway I am almost sure that it is not feasible to set a more > visible directory for the socket and to request > com.apple.security.files.user-selected.read-write from sandbox. > As local domain sockets are tied to the file system, Apple has precluded their usage as IPC for hardened runtime apps as they exist outside an app’s sandbox. > Is it possible to invoke emacsclient or to connect to Emacs socket from > native messaging helper for a browser extension? No. Browser extensions without relaxed security permission can not call executables like emacsclient outside the sandbox of their host browser. One could implement a browser extension that implements the TCP client functionality of emacsclient, but it would also require permission to access the Emacs server shared secret file. > Frankly speaking, I expected to find more discussions and complains related > to emacsclient on macOS, but quick search gives mostly outdated results. This might reflect that there are _so_ many hoops to jump to make Org Protocol work, sandboxing or not. Most Org mode users get funneled out because of this. > > P.S. It seems macOS desktop/laptop security model became indistinguishable > from mobile OS where data are tightly sealed withing each app. I’d reflect that this is a direction that all the major OS vendors have gone with contemporary app packaging and distribution. UWP for Windows and Flakpak for Linux comes to mind. — Charles Y. Choi, Ph.D. kickingve...@gmail.com
