Mojave and apple events sandboxing


(Jean Christophe Helary) #1

It looks like Mojave sandboxes apple events between applications:

Do beta testers have comments on that ?


(Shane Stanley) #2

Yes, there will be one-off authorisation required before an app can send events to another app. There will be some exceptions — including unsigned applets —but it will probably be more annoyance to end-users than scripters.

There’ll also be restrictions on accessing some protected data (emails, picture library, contacts, etc) which will be more problematic to work around.

The article you refer to makes some good points, although I suspect most of them won’t matter too much to most scripters. However his request to be able to whitelist apps, and do it in advance, would certainly be useful in some case. I think it would be useful for scripters to duplicate his bug with Apple, to hopefully give it a bit more weight.

Longer term, the move to compulsory notiarization of codesigned apps will probably require a bit more thought.


(Ray Robertson) #3

Thanks for the explanation. By “one-off” I’m assuming that means in the lifetime of the app. So if we distribute an applet, for instance, the first time the user runs it, there will be a notification for each app it sends an event to, and it will likely be best practice to have code at the beginning of the script to tickle each app and allow time for the user to dismiss notifications.

But will this happen again each time we send an upgraded version of the applet? Do you think that will be name dependent only, so if we simply keep the name identical there are no more notifications?

The ability to Whitelist an app would be great, although I’d much prefer a way for the user to simply do a one-time whitelist authorization to all apps code-signed by a particular developer. That would help better justify what has become a now-compulsory $99 payment to Apple every year.

I’m not seeing the potential harm in a whitelist based upon developers. Surely Apple can track and see small-fry developers like me have a limited number of apps out there, and the risk of much damage if I suddenly “go rogue” would be minimal.


(Shane Stanley) #4

Yes. (The user can of course change their mind in System Preferences.)

That sounds a reasonable approach. It’s only going to get awkward if the user panics and says no at some point.

Not if you don’t change the UTI.

I presume it will UTI-based.

It’s not so much your going rogue as malware using your apps as a pathway. On that basis, “small-fry” developers are arguably every bit as big a risk.


(Ray Robertson) #5

Thanks for the explanation. I’m more grateful than ever for the features in the Resources tab in SD7.


(Ray Robertson) #6

Hmm…So working in High Sierra now, when I export from SD to run-only in a code-signed script, the bundle identifier in the run-only script is based upon the name of the original editable script, rather than name I give to the run-only script. Is this expected behavior?


(Shane Stanley) #7

Yes. The idea is that the contents of the run-only version generally differs only in its run-only-ness.


(Ray Robertson) #8

OK. I’ll edit the bundle ID in the master to match the run-only name. But great, great word usage with run-only-ness. I will definitely use that in class! :slight_smile: