A long time ago, dkmarsh kindly posted this neat little AppleScript that copies the URL of your current Safari page to your clipboard...


Today, out of the blue, the script stopped running, with this cryptic entry in Consolebeing my only indication of why.

I invoke the script with a Butler hotkey, so I immediately suspected it as the culprit, but all my other scripts ran as expected.

I then began experimenting by recompiling the script and saving it to my scripts menu, but with the same unexplained non-fuctionality.

Next, since both failed instances were invoked via "3rd parties", I tried saving the script as an app, and BINGO!

The first time I tried to run it I got this pop-up, and, indeed, enabling the option (and authenticating) restored my hot key to functionality.

A new wrinkle in Safari 9.1.1, I guess, although I can't guess its purpose.

(Safari's Develop menu can be installed in your menu bar via Safari > Prefs > Advanced > Show Develop menu in menu bar.)

Apple is now allowing users and developers to write AppleScripts in JavaScript as well as AppleScript (seriously, you can now use the Script Editor to type scripts in straight JavaScript, it's pretty cool), but, what one hand giveth, the other hand taketh away.

Allowing AppleScript to control apps using embedded JavaScript potentially presents a security hole; a malicious Web developer could use an embedded JavaScript to wreak all kinds of havok. So, to prevent that, Apple now requires you to explicitly permit JavaScript to control apps.

Thanks for explaining the new feature and its attendant back door, tacit.

But how do the two options offerred

1. Allow JavaScript from Smart Search Field
2. Allow JavaScript from Apple Events

fit into the picture?

Edit: And how on Earth am I supposed to know whether any script incorporates it?

Edit 2: And in selecting the "Allow...." option haven't I opened my own back door?

Actually, with the installation of JavaScript OSA, scripting Apple Events in JavaScript has been possible for years.

Beyond that, the do JavaScript command has been a part of Safari's AppleScript library since Safari 2, so the potential security hole has been around a long time.

Edit: It's not clear to me whether other applications can send Apple Events to Safari invoking JavaScript commands. If so, that obviously represents a much bigger vulnerability...

Allow JavaScript from Apple Events [edit: in the context of this particular script] basically means "allow AppleScripts to invoke Safari's do JavaScript command."

How does Allow JavaScript from Smart Search Field fit into the picture?

Under any circumstances, though, the newly implemented "protection" is practically useless as far as I can tell, because having allowed your script to run has apparently enabled ALL such scripts.

To be effective, "Allow JavaScript...." needs to maintain a menu of allowed scripts and question new ones.

Edit: Allow JavaScript from Smart Search Field apparently means (literally) Allow JavaScript in Smart Search Field.

Well, you could always enable the setting, run the script, and then disable it again. In fact, it might be possible to write an Applescript script which does exactly that! (Although such a script would itself require authorization via System Preferences -> Security -> Privacy -> Accessibility...)

I've already thought of the enabling/disabling routine, but this is OS X, and security shouldn't be that cumbersome even if I hot key the task in System Prefs > Keyboard > Shortcuts > App Shortcuts. Apple really and surprisingly dropped the ball on this one...didn't think the problem through to its logical end.

I haven't got anywhere near enough facility with AppleScript to write the one you've suggested.

I've submitted a "feature enhancement" request to Apple, and in the meantime I'll just run in accessible mode as I've been doing for years.

I just want to point out your "feature enhancement" involves a Developer Menu item, the Developer Menu is not enabled by default, therefore only a very small number of users are even aware of the Developer Menu's existence, an even smaller number have it enabled, and of that number only a vanishingly small number have any idea of its significance one way or another. I suspect Apple would be happy to drop the options entirely if it weren't for their desire to support developers. Maybe to an unpublished preference item.

I get your point, but Apple did go to the trouble of coding in the option, and if they feel that it's necessary they ought to get it right.

And maybe we're talking about a necessary security feature that's just been misplaced.

I'm not sure what you meant by "Maybe to an unpublished preference item."

Poor choice of words on my part, I should have said undocumented instead of unpublished. For example Koingo Software's MacPilot contains some 1,200 hidden and/or not obviously documented preference settings for OS X and the Apple apps. It is amazing how much customization is possible without hacking any software. I could spend weeks perusing the various developer documents and find some of the hidden options but it is far easier to simply launch MacPilot.

DISCLAIMER: I have no pecuniary or other relationship with Koingo Software other than being a satisfied customer of some of their products.

Thanks for the clarification.

It seems to me, though, that undocumented security isn't a whole lot better than none at all.

I'd suggest moving the option to Preferences > Security. (The JavaScript option we're discussing doesn't even appear to me to have anything to do with development; I'm not sure about the other one.)