macOS 14: "Zotero.app" would like to access data from other apps

[dstillman]

The first developer beta of macOS 14 shows a permissions prompt at every startup in Zotero 6 and 7, after this line:

IPC: Initializing pipe at /Users/dan/Library/Containers/com.microsoft.Word/Data/.zoteroIntegrationPipe

This seems to be the Full Disk Access permission, since I get this when starting from the terminal if I disable that permission for my terminal app. I don't recall ever seeing this before, but I guess they added it for when an unsandboxed app tries to access another app's sandbox folder.

I assume it's a bug that it's prompting every time and not adding Zotero to the list in Full Disk Access, and we could file a feedback for that, but do we actually need to use that location? It would be nice to avoid the prompt altogether if we could.

[dstillman]

I assume it's a bug that it's prompting every time

Not a bug!

https://lapcatsoftware.com/articles/2023/6/1.html https://developer.apple.com/videos/play/wwdc2023/10053/?time=1066

So we need to stop accessing Word's container. And we probably need to fix this in Zotero 6 too.

[dstillman]

So the problem here is that Word is sandboxed, so it can't access files outside of its container, and that's why Zotero switched to creating a pipe within Word's container. But external access to an app's sandbox is now restricted in Sonoma with a prompt that only gives permissions while the app is open. To avoid that, users would have to go to System Settings and manually grant Zotero full disk access. (It's possible we could prompt and open that specific prefpane, but that's still something we really don't want to ask for. Zotero of course already needs full disk access for all sorts of reasons, but it's a scary-sounding thing to ask for.)

A sandboxed app can get entitlements to access files outside of its sandbox, but only for specific things. It looks like Word has read-only access to movies, music, and pictures, a special entitlement for read-only access to /Library/Application Support/Microsoft/, and write access to user-selected. So those would not seem to help — even if we stored the pipe in ~/Pictures, presumably Word would need write access — and I'm not seeing anything else relevant. (To see entitlements, run codesign -d --entitlements - --xml /Applications/Microsoft\ Word.app/ | xmllint -format -.)

The one thing I'm not sure about is whether there's any folder that's globally accessible to sandboxed apps without an entitlement. I'm not seeing that in the documentation. It would also presumably have to be predictable so that Zotero could create the pipe there — it can't just be a random temporary folder.

So I'm not sure we have a great solution here other than switching to the JS API. By October…

[adomasven]

So I'm not sure we have a great solution here other than switching to the JS API. By October…

Well at least the field api changes have been deployed to Mac Word 16.70, so it's probably technically feasible https://learn.microsoft.com/en-us/javascript/api/requirement-sets/word/word-api-requirement-sets

Although it's likely we won't be able to install the plugin into Word from Zotero, so that's going to complicate things in a different way. And reading the deployment page for js addins is a bit dreadful https://learn.microsoft.com/en-us/office/dev/add-ins/publish/publish

[dstillman]

Well, an occasional prompt to install/update Zotero.dotm would be OK — we'd show a warning first.

It also occurred to me that Zotero.dotm could perhaps send an Apple Event to Zotero instead of writing to a pipe. We could probably update Zotero to accept that if we had to, and there'd at least be a clear permissions request. So maybe that's a more realistic short-term solution here, if we don't make a lot of quick progress on the JS API.

[dstillman]

Or I guess you meant install the JS add-in? I think we knew those were AppSource only. I'm not too concerned about that — we already distribute the Edge extension through Partner Center, and we can direct people there easily enough.

But the app sandbox change will presumably also prevent us from installing Zotero.dotm into Word. (I assume the restriction applies to Group Containers too.) I think we can deal with that with a popup, though, which Apple advises you to do anyway before triggering the Full Disk Access prompt.

So we just need to find another way to pass commands to Zotero from Zotero.dotm.

[adomasven]

It also occurred to me that Zotero.dotm could perhaps send an Apple Event to Zotero instead of writing to a pipe. We could probably update Zotero to accept that if we had to, and there'd at least be a clear permissions request. So maybe that's a more realistic short-term solution here, if we don't make a lot of quick progress on the JS API.

We can probably do that and it's a better idea, although then Word will probably trigger a prompt that it wants permissions to automate Zotero. Although perhaps our app can explicitly grant access to some bundle names by default?

But the app sandbox change will presumably also prevent us from installing Zotero.dotm into Word

Yep, seems that way.

[dstillman]

I'm not seeing any way to grant events access to another app.

But curl works:

MacScript "try" & nl$ & "do shell script ""curl http://127.0.0.1:23119/connector/ping""" & nl$ & "end try"

[dstillman]

Resolved for Sonoma last year, but now we have https://github.com/zotero/zotero/issues/4526 for Sequoia.