Launch agent as XPC on mac store with Safari Web Extensions

I would like to know if this will be accepted by the App Store.

App Review has the final say as to what is or isn’t allowed on the store. I don’t work for App Review and thus can’t give you a definitive answer. However, my experience is that App Review rarely approves the user of App Sandbox temporary exception entitlements.

Are there alternative communication methods as I definitely need to talk to this external app?

Have you thought about having the external app talk to your product? Assuming that external app isn’t sandboxed, that’s an easier option because the App Sandbox puts fewer restrictions on in-bound communication.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@eskimo I assume this inbound communication would happen through Apple Events. Would it be feasible to reply to these events as well as the communication needs to be bidirectional?

How is a man in the middle attack prevented with Apple Events?

What if the sandboxed app and the unsandboxed app are code signed by the same developer, would that make a difference with the use of temporary exception entitlements?

I assume this inbound communication would happen through Apple events.

That’s one option, but not your only option.

Would it be feasible to reply to these events as well as the communication needs to be bidirectional?

Yes. Apple events use the request/response model, and the Apple event subsystem ensures that, when you receive an Apple event request, you’re granted the capability to reply to it.

How is a man in the middle attack prevented with Apple events?

Apple events are traditionally targeting via bundle ID, which is definitely susceptible to Mallory-in-the-middle attacks. However, there are other targeting models, like typeProcessSerialNumber, that are not easily impersonated. The receiver can also use Apple event attributes to further validate the sender (like keySenderApplicationIdentifierEntitlementAttr).

What if the sandboxed app and the unsandboxed app are code signed by the same developer, would that make a difference with the use of temporary exception entitlements?

Being signed by the same team has interesting technical implications but the the sticking point with temporary exception entitlements is not technical but rather App Review, and I can’t give you definitive answers about their policy.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@eskimo

That’s one option, but not your only option

What are some other alternatives? From my understanding, IPC with Mach Ports, Unix domain sockets, and shared memory require temporary exception entitlements.

Yes. Apple events use the request/response model, and the Apple event subsystem ensures that, when you receive an Apple event request, you’re granted the capability to reply to it.

Is it possible to indefinitely wait for the reply?

What are some other alternatives?

The most obvious is Unix domain sockets.

From my understanding, IPC with Mach Ports, Unix domain sockets, and shared memory require temporary exception entitlements.

No. Well, yes, but no. The sandbox prevents outgoing IPC connections but not incoming ones. So, for example, consider Unix domain sockets:

• If your non-sandboxed code creates a listening socket at some arbitrary location in the file system, your sandboxed app will not be able to connect to it.

• If your sandboxed app creates a listening socket in its container, your non-sandboxed code will be able to access it (subject to traditional Unix permissions checks).

Also, many IPC mechanisms have a specific affordance for App Groups. See IPC and POSIX Semaphores and Shared Memory in the App Sandbox Design Guide.

Is it possible to indefinitely wait for the reply?

Yes.

On the client side you specify a timeout as part of the event. On the server side, you can suspend the event indefinitely and then resume it when you want to reply.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@eskimo

Also, many IPC mechanisms have a specific affordance for App Groups. See IPC and POSIX Semaphores and Shared Memory in the App Sandbox Design Guide.

If we go this route, this would mean having a bidirectional communication that does not let the app extension rely only on replying to events, rather it can initiate outbound requests to the listening socket on the unsandboxed app correct?

The same applies to using UNIX domain sockets without the app groups