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:


(Jim Underwood) #9

i’m seeing reports that every time an app using AppleScript in Mojave beta 6 tries to access Safari or Chrome, it asks for authorization. Not just once, but every time. Anyone seeing that here?

If so, seems like this kills automation. If every time an AppleScript tries to get data from one app to store in another app, the user is forced to confirm for both apps, then many users will reject the script.


(Shane Stanley) #10

NDAs limit what can be said about Mojave, however what you describe is not the case.


(Phil Stokes) #11

About the only publicly discussable information on this is at the moment is what was said here:

https://developer.apple.com/videos/play/wwdc2018/702/

Aside from that, any reports you see about AS and Mojave are really beta-testers fuming in public when they should be just quietly submitting the bugs to Apple. There are Apple-hosted private and public discussion forums available for those people, so why they can’t stick to them (and the NDA) is both a mystery and a bit annoying (in that it unnecessarily worries other folk who should just relax and wait for the public release). :smiley:


(Mark Alldritt) #12

Here is the the Mojave documentation that accompanies Script Debugger 7.0.4. If you have Mojave concerns or questions relating to Script Debugger, please post them on the private Script Debugger Beta section of the forum.


(Ed Stockly) #13

https://latenightsw.com/mojave-brings-in-big-security-changes

This link at the end of the documentation page seems dead.


(Mark Alldritt) #14

Thank you for pointing this out. We are holding back on releasing that post until Mojave ships and we know more and we are able to speak more freely.