Persistant Privacy and Automation warnings

Presumably you approve each of these accesses? If so, that fact should be remembered and you shouldn’t get the same alert again. If it’s not being remembered, the most common cause of that problem is a lack of code signing, or code signing that’s not stable.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

The code was not previously signed....and the approvals were not being remembered.

We are in the process of getting setup with a dev account so that we can sign and recompile all of these.

Is there no way to disable this entirely? Even if the approvals were remembered, it still poses a HUGE set back to our workflow.

We are in the process of getting setup with a dev account so that we can sign and recompile all of these.

Cool. The issue here is that the code signature uniquely identifies the code, so if the code is not signed there’s no way to know that one instance of your app is the same as another instance [1].

Is there no way to disable this entirely?

That depends on your deployment setup. If you’re deploying to a wide range of normal users, there’s no way to disable this feature (which kinda makes sense, in that this is a security hardening). If you’re deploying to a managed environment, you can configure this via the privacy preferences control (

com.apple.TCC.configuration-profile-policy

Of course, that requires that your apps be signed because that’s how the payload identifies the apps that it applies to.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] Historically there were ad hoc ways to do this, but these have fallen by the wayside now that code signing has reached a critical mass.

We are now able to sign using the DEV account....and that just broke everything.

Previously it was asking, over and over and over, for permission to interact with other software. Now it simply will not run, instead returning an error "________ is not authorized to send apple events to ________" or similar.

Now nothing works.

First up, make sure your

Info.plist

NSAppleEventsUsageDescription

Second, if you signed with the hardened runtime enabled, make sure you also have the Apple Events entitlement (

com.apple.security.automation.apple-events

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

“The issue here is that the code signature uniquely identifies the code, so if the code is not signed there’s no way to know that one instance of your app is the same as another instance”

OP might consider deploying scripts via the global script menu (enabled via Script Editor’s general preferences) or third-party launcher, rather than as standalone applets (which need to be individually codesigned and immutable). Being conventional macOS .app bundles those should provide a stable target for the OS’s identity checks to latch onto, unlike traditional Script Editor applets which are notoriously self-modifying.

Yeah, associating signatures with executables rather than scripts is a loophole in the current security setup which may eventually be plugged. But until Apple figures out what its future IPC and end-user automation strategies are going to be and makes it happen, might as well make the most of those holes. It’s frustrating all round.

Appreciate all the feedback on here. Unfortunately deploying from within an app isn't a real option. The largest point of these apps is drag/drop functionality. We pull a lot of data from the files paths and names and save a lot of time.

It would be a massive step backwards to require browsing to files.

So what is your plan when Apple Script and Finder are no more?

So what is your plan when AppleScript and Finder are no more?

While I’m a big fan of planning for the future, planning for a future without the Finder is kinda pointless. It’s been with us since 1984 and there’s no indication of it going away.

As to AppleScript, I imagine it’ll see some significant changes as the system evolves, especially around security, but I think you need to be careful not to get too wrapped up in rumours of its imminent demise. AppleScript has been around since the early ’90s, and it’s shrugged off such rumours many times in the past.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

ps DTS is closed 21 Dec through 1 Jan.

planning for a future without the Finder is kinda pointless. It’s been with us since 1984 and there’s no indication of it going away.

I am speaking in terms of a developer's perspective. I wouldn't consider a 10-fold increase in potential customer base to be a pointless exercise. Developers should code to a stable and reliable API and be purposefully ignorant of other apps that might be running. That way, they aren't restricted to a market of only people with that app and aren't at risk when the developer changes said app. The Finder is Apple's app and any kind of programmatic interaction with it should be considered high-risk.

(Maybe, if one's entire business is Finder extensions or Photoshop plug-ins, it might be different. But even in those cases, one would be coding to an API and hopefully more aware of one's absolute dependency on a hosting app.)

As to AppleScript, I imagine it’ll see some significant changes as the system evolves, especially around security, but I think you need to be careful not to get too wrapped up in rumours of its imminent demise. AppleScript has been around since the early ’90s, and it’s shrugged off such rumours many times in the past.

It's no rumor. This thread is a good example of that. There is an entire class of apps that have been killed off by the new AppleScript permissions model. A developer can start signing apps and updating plist files and make it work again, but it's not the same.

This is a huge barrier to adoption by new users. Existing users are already invested in an app and most of them can be instructed and persuaded to make all the appropriate system settings to continue using their app. But many new users won't bother.

I'm not saying that is always a bad thing. Unlike some people 🙂, I was never a fan of AppleScript to begin with. But this is more than just an AppleScript issue. When Apple makes a fundamental change to some aspect of the platform, such as the security model, or the app discovery/installation model (i.e. App Store) developers would be wise to adapt both their software and their business models. These are more than just changes to technology, they change customer behaviour too. Some apps just aren't viable anymore. An app that works on iOS and pays the rent from iOS sales can be adapted to the Mac. If done properly, it could even gain capabilities and features, potentially making the porting effort worthwhile.

“The largest point of these apps is drag/drop functionality.”

Yeah, I did consider that possibility. Droplets are just too **** handy in a production environment. Code signing would be best; unfortunate that costs $99/year but if it’s a business I’m sure they can absorb that. (If only Adobe licenses were that cheap!)

One of the challenges with Script Editor applets is that they tend to mutate themselves. (I think AppleScript took some ideas about persistency from Smalltalk VMs; a noble ambition, but goes down in *nix OSes with retrofitted user-level security like a lead balloon.) Off the top of my head, the easiest way to defeat that is to modify its entry point(s) like so:

on run
    -- do stuff
end

becomes:

on run
    local scpt
    copy me to scpt
    tell scpt to _run()
    return
end

on _run()
    -- do stuff
end

That should make a copy of the entire script, run that copy, and discard it. This prevents any changes to properties/globals being saved back to the applet bundle’s embedded script file, so the applet’s resource files should remain stable. I think (but don’t quote me on this) that Xcode-saved applets might be non-persistent too.

Unfortunately, I don’t have access to a 10.15 machine right now to see if that makes any difference to Automation permission requests. If it does help, let us know.

“AppleScript has been around since the early ’90s, and it’s shrugged off such rumours many times in the past.”

The other thing that was around since the early ’90s was the Mac Automation/AppleScript development team. Even after its original creators quit in frustration at the lack of support, there was still a team to [nominally] work on it. However, the Mac Automation team got canned in 2016; and while I completely agree with Apple’s firing of its manager (and wish it’d had been done a decade sooner when a new manager could’ve been appointed to turn it around), it is apparent there are no longer any engineers tasked to AppleScript and its related technologies beyond a minimal maintenance role. (And even those minimal API additions made to accommodate securty are half-baked and poorly tested at best.)

Beyond that, the AppleScript language itself is at the end of its lifecycle, and with no apparent moves to straighten out the very dated and arcane Apple event IPC systems that underpin it and bring that technology to iOS, it’s painfully obvious it has no future beyond slowly rotting away. All that tech all be fixed/replaced/reinvigorated, and reborn as the cross-platform cornerstone for all high-level interprocess communication and end-user automation, but there’s nobody left to do it; and even when there was they had no clue why or how! (Which is why there is nobody now.)

Even Soghoian dropped broad hints post-ejection that Apple envisages the future of cross-platform automation in Siri-based technologies (now including [conversational] Shortcuts) and App Extensions, and he was the one who cratered its predecessor. And that is not necessarily a bad future, but it is still one far less capable or flexible that what could’ve, should’ve, would’ve had by now had the Apple events stack not been long since run into the ground.

I know Apple seriously restricts individual employees discussing current and future plans, but I wish someone there would just be honest and officially declare the whole technology stack Legacy Technology to be Deprecated in a future release of macOS, so that all users now know exactly where they stand and can plan their own futures accordingly.†Yes, radical change hurts and they’ll complain like ****, but it’s still massively less damaging than radical change with zero notice.

--

† (And if you lose a few print shops to Windows as a result, so what? That hasn’t been a key market for Apple in 15 years, and is probably more trouble than it’s worth. At least with a timeline they can migrate sensibly, and customers generally appreciate a vendor—even an ex-one—who treats them professionally and doesn’t burn their business from under them.)

I wish someone there would just be honest and officially declare the whole technology stack Legacy Technology to be Deprecated in a future release of macOS, so that all users now know exactly where they stand and can plan their own futures accordingly.

All that would do is generate bad press. Haven't you seen any of the code signing or Notarization threads? Or what about all the "32-bit" threads over on Apple Support Communities? The people that such a declaration is meant for would be oblivious to it. Apple practically displays its roadmap strategy on the roof of Apple Park for all to see. Developers who can't read those 4-story tea leaves probably shouldn't be developing on Apple platforms. It isn't going to be an enjoyable experience for them or their customers.