It looks like Mojave sandboxes apple events between applications:
Do beta testers have comments on that ?
1 Like
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.
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.
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.
Thanks for the explanation. I’m more grateful than ever for the features in the Resources tab in SD7.
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?
Yes. The idea is that the contents of the run-only version generally differs only in its run-only-ness.
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! 
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.
NDAs limit what can be said about Mojave, however what you describe is not the case.
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). 
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.
https://latenightsw.com/mojave-brings-in-big-security-changes
This link at the end of the documentation page seems dead.
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.
1 Like
Without knowing their current authorization status, apps can’t guard against triggering an authorization prompt that blocks their sending thread indefinitely.
go on this Linksys Router Support
if you face the router problem.
Man does that dialog get annoying when you see it for like the hundredth time… 
1 Like
iOS automation is starting to look relatively friction-free …
1 Like
I monitor Twitter for anything AppleScript related and the amount of confusion caused by Mojave’s AppleEvent security changes is vast. It’s effecting Automator, AppleScript, Keyboard Meistro, TextExpander, and everything in between. Since there is no documentation on from Apple, people are trying to divine the workings of the macOS automation black box for themselves.
Apple has really dropped the ball on this breaking change. There is no mention of any of this in the 10.14 release notes. It has fallen to developers to try and explain the consequences of these changes relative to their products. What a mess.
What’s the best channel for people to use to ensure that cries of pain are plainly audible in the infinite loop or apple park ?
File bug reports with Apple. Don’t yell, scream, lecture or threaten. Explain what is not working and how to reproduce it using Apple’s software - one issue, one bug report. Explain how the change is harming your business or your use of macOS. Consider each bug report with Apple to be a vote. Nothing happens within Apple without a bug report.
Don’t expect them to reverse these changes - a hardened macOS is clearly the future. But we can encourage them to improve the implementation so its less of a problem.
P.S. The people implementing this stuff are not dumb. I just think the full ramifications of what they are attempting to do were not understood. I have no direct knowledge, but I suspect the people doing SIP decreed new restrictions in Mojave and all the groups doing software higher up in the stack were trying their best to deal with this change.
3 Likes