Archive for August 31, 2018

Friday, August 31, 2018 [Tweets] [Favorites]

AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms

Felix Schwarz (tweet):

macOS Mojave beta 7 introduced AEDeterminePermissionToAutomateTarget, a new API that allows apps to determine whether they’re authorized to send an AppleEvent to another app:

OSStatus AEDeterminePermissionToAutomateTarget( const AEAddressDesc* target,
						AEEventClass theAEEventClass,
						AEEventID theAEEventID,
						Boolean askUserIfNeeded );


Also new in macOS Mojave beta 7 is kAEDoNotPromptForUserConsent, a flag that can be added to the AESendMode that’s passed to AESend().

If the AppleEvent sent that way would require user consent, the user is not prompted for consent. Instead AESend() will return errAEEventWouldRequireUserConsent.

What’s up with the documentation this year? We’re now on beta 9, but Apple hasn’t mentioned this important stuff anywhere but the headers. And there are still no release notes for Foundation, Core Data, and other frameworks besides AppKit.

AppleEvent sandboxing, as of Mojave beta 9, is not in a good shape. The addition of new APIs in beta 7 telegraphed that Apple is still working on it. But it’s unclear what changes are still in the pipeline - and whether Apple can make enough progress before Mojave’s public release.

Apple has been talking a good game lately about the Mac and professional users, but actions like this either make it seem like mere talk or point to division within the company. The general idea of AppleEvent sandboxing is not a bad one, but the rollout was botched. Apple did not seem to be aware of how disruptive this would be for developers or how much it will degrade the user experience for customers. That is impossible to square with the idea that it understands and cares about pro users. Or, alternatively, Apple understood this but development was way behind schedule and, for no discernible reason, it decided to rush ahead rather than take the time to get it right for macOS 10.15.

Mark Munz:

Given Mojave b9 created a whole NEW set of display problems in app (none which existed in any prev beta) does not give me encouragement that Apple will fix #AEpocalypse in time or in a user-friendly manner. #bigmess


And it will be individual developers that will be left to try and work around Apple’s rushed decision making and half-assed implementations. This stuff feels seriously rushed.

Dave Nanian (tweet):

When a schedule starts, those prompts suddenly appear, referencing an invisible application called Copy Job. And while a user might recognize a prompt for SuperDuper, it’s quite unlikely they’ll know what System Events is, or why they should allow the action.

Worse, a typical schedule runs when the user isn’t even present, and so the prompts go without response, and the events time out.

Worse still, a timeout (the system defaults to two minutes) doesn’t re-prompt, but assumes the answer is “no”.


It’s more than a bit ironic that an approach that avoids the prompting can do far more, silently, than the original ever could, but that’s what happens when you use a 16-ton weight to hammer in a security nail.

Jason Snell:

This is such a disaster.

Dave Nanian:

My blog post’s summary video[…]

Rich Trouton:

As part of macOS Mojave, Apple introduced new controls for accessing data in the individual user home folders. Along with these controls, Apple introduced the ability to whitelist certain actions and interactions using profiles. This repository stores Privacy Preferences Policy Control profiles, also known as TCC profiles, which I’ve created using the following tool[…]

Previously: Apple Event Sandboxing in macOS Mojave Lacks Essential APIs, Apple Events Usage Description.

Update (2018-09-03): Felix Schwarz:

Using the x-apple.systempreferences URL scheme, it’s possible to open System Preferences right at “Security & Privacy > Privacy > Automation” by opening this URL[…]


Passing false, errAEEventWouldRequireUserConsent is returned even if the user was previously prompted and declined permission.

In consequence, even for running applications, AEDeterminePermissionToAutomateTarget can’t be used to silently determine the current status. To be usable for that, it would need to return errAEEventNotPermitted in case consent is required and the user has already been prompted about it and denied. This feels like a bug. Paulo Andrade has filed a radar about it.

Felix Schwarz:

Hidden gem in there: “TCC stands for transparency consent and control.”

Update (2018-09-04): The URL for opening the Full Disk Access preferences is:

Rui Carmo:

It’s not going to be the usual “fallback, update and regroup” update where it regards scripting and automation—there will be some serious breakage due to new security measures.

Paulo Andrade:

So in many of these cases the prompt has a negative effect on user experience, can be misunderstood, and contributes even further to numbing down the importance given to security alerts (which ultimately defeats the purpose of having any).


Automation has always been a staple of macOS. And there was a time where it was booming. Apple gaves us Automator, the Scripting Bridge and bindings to other programming languages. The excitement you see today regarding Siri Shortcuts, us Mac users, we’ve experienced it before.

But a few years back (I can’t precise when), development stopped. And the only thing we would hear at WWDC was how signing, gatekeeper and sandboxing were affecting our applets, automator flows and APIs.

Paul Kim:

I cannot run a number of my automated tests. My tests test functionality that uses AppleEvents or the tests use AppleScripts themselves to verify test results. Adding the usage description keys to the Info.plists of the xctest bundles does not work. Also, it’s unclear which app the keys should be added to as it’s not documented whether a helper app, or its enclosing app needs to include them. On top of that, I don’t own the running app in this case so changing those keys will break the code signature.


In short, unless Apple fixes this soon, or even better, rolls it back to be released later, things are going to be a bit bumpy in Mojave. As a user, you may be surprised how often AppleEvents come up in the apps that you use.

Update (2018-09-05): Felix Schwarz:

The issue mentioned by @dnanian’s blog post – where AE prompts automatically timed out with “Don’t Allow” after a few minutes – seems to have been addressed: I have one open for 32 minutes now.

Other than that, I didn’t find any changes in beta 10.

Dieter Komendera:

The new Apple Event Sandboxing in macOS Mojave is going to be a disaster. This is the alert when auto-filling credentials from 1Password (v. 6.8) in Chrome. Normal users will bump into this & break their system.

Hal Mueller (tweet):

However, the view controller that needs camera and microphone access has multiple previews, and a live audio level meter. The calls from AVFoundation to request access are asynchronous. That means that bringing up that one view controller triggers six different alerts in rapid succession, each asking for camera or microphone access. That’s not a user experience we want to present.


There’s another complication, though. The user alert for each kind of privacy access (camera, microphone, calendar, etc) is only presented once for each application. If they clicked “grant”, that’s great, and we’re off and running. If they clicked “deny”, though, we’re stuck. We can’t present another request via the operating system, and we can’t bring up our recording preview.

Enter the nag screen. The nag screen points the user to the correct Privacy & Security pane. We will show the nag screen (optionally, depending on a parameter to our gatekeeper method) from the completion handler if permission is not granted.

Hal Mueller:

Consent for automation (using AppleScript) is more complicated. You won’t know whether you can automate another application until you ask, and you won’t find out for sure unless the other application is running. The API for automation consent is not as well-crafted as the API for other privacy consent.

Felix Schwarz:

Contrasting this #WWDC2012 slide with #Mojave’s AppleEvent sandboxing implementation provides a strong argument for why the latter should really be built on top of AppleEvent access groups:

- increased security

- better privacy protection

- prompt the user only if really needed

Building #Mojave AE sandboxing on AE access groups would also allow for a MUCH better prompt & full transparency – by enabling macOS to show EXACTLY the list of permissions requested.

“Allow app X to send an email?” vs. “Allow app X to do anything in Mail?”

Felix Schwarz:

In 2017, User Approved Kext Loading shipped, even though it was clear it’d cause lots of pain

The impact on my app sales was/is immense.

If AE sandboxing ships as-is, affected devs can expect refund requests, 1 star ratings & LOTS of mail.

Felix Schwarz:

If Apple insists on shipping AppleEvent sandboxing as-is, it’ll cause a lot of breakage for normal users.

And no time will be wasted by the media to (deservedly) mock Apple with their own ad.

Both of which would be a shame, because #Mojave is a really solid update otherwise.

Update (2018-09-06): Howard Oakley:

Mojave’s protection system, TCC (for Transparency Consent and Control), has to work with old apps, built before these controls were implemented, and new ones, which may have the protection of being App Store apps, or can be ‘hardened’ and notarized. To cope with this wide range, its rules may appear complex, so I have sketched them out in a diagram which explains what happens when an app tries to access protected data.

Update (2018-09-07): Norbert Doerner:

Honestly, I have never seen Apple adding such essential limitations so late in the beta. In this case, in beta 6. Add that to the more or less complete lack of communication about this vast limitation, and you are bound for trouble.

The limited way that Apple seems to offer to developers to tell the users why they want AppleEvent access to an app (only a single text string per application for all AppleEvent-related actions to all possible other applications!) - and the very lame idea from Apple to name this new dialog “xx wants to control yy”, will cause all kinds of important features in so many apps to break.

Developers now suddenly need to test every single one of these places in their code and add graceful, defensive code that explains to users, if and why a feature failed in macOS 10.14.

Howard Oakley:

The strange thing with apps created by the Script Editor is that it does what everyone agrees you shouldn’t do: it adds usage information for every class except Location services, as shown in this shot from Taccy.

Building scripting into Mojave’s privacy control is not easy, nor is it yet complete. I think that Apple is going to have to provide more extensive support to app developers, and the human interface will inevitably improve. It would make a great deal of sense for apps to be able to obtain pre-approval when first opened, so that users can give their consent to the features that they have just paid for, to access their own data. But this is going to require great care, for fear of opening vulnerabilities which will allow rogue apps to exploit the system.

Mark Aldritt:

The first time you run a script that addresses an application, you will be asked to grant your permission. If you do not, the script will not run. Script Debugger’s Dictionary Explorer works by sending Apple events to applications, so you may be asked for permission when exploring an app’s dictionary, rather than directly running a script.

Update (2018-09-08): Mark Munz:

With macOS Mojave, I feel we’re returning to an Apple attitude of just dictating terms to Mac Devs instead of engaging with them.

1. User prompts for every app that uses AppleEvents.

Oh, guess what? A lot of apps use AppleEvents! That means A LOT of user prompting.

Who doesn’t love a ton of random prompting?

2. And if you choose poorly…

Like Indiana Jones & Last Crusade, the results are bad.

Right now, you have to make a trip to terminal. To me, that’s a demonstration of failure in this Mac UX.

3. AppleEvent security is important, but it needs CAREFUL consideration. IMHO, Mojave’s solution is not that.

It feels very half-baked. It feels like there was NO dev input sought before WWDC. And we are now using band-aids to try and “fix” some core design flaws.

4. And 3rd party developers will end up taking the brunt of the complaints by users.

It will be our support teams overwhelmed with complaints that (64-bit) apps that worked in High Sierra are now broken.

Jeff Johnson:

The more warning dialogs you present to a user, the more they just click through without reading. This is well known. How does Apple not know?

Or maybe they do know. The Mojave warnings are not to protect users, they are to protect Apple from blame. It’s your fault for clicking.

Update (2018-11-19): Tim Hardwick:

I’ve been testing Folder Actions in macOS Mojave 10.14.1, and the results aren’t good. Apple needs to look at how new security approvals are implemented for workflows containing Apple Event scripts, because the reliability of automated actions has taken a dive.

Update (2018-11-26): Jesse Squires:

This was my first real experience trying to write a Mac app after years of doing iOS development and the majority of my time was spent trying to understand how sandboxing works and which entitlements I needed to specify.

Update (2018-12-20): Paul Haddad:

The security model in Mojave is awful. Why isn’t this just Deny/Allow? Half of these types of calls pause execution, half fail. No way to re-ask. Just bad.

Adding isMultiple(of:) to Swift’s BinaryInteger

John McCall:

It is substantially more fluent than its standard implementation of value % divisor == 0. Divisibility testing is the operation people actually want; the % operator is just the way they have to achieve it. % is rarely used outside of this idiom, and many programmers have no other reason to know it. It is not a familiar operator for new programmers especially: they will usually be comfortable with remainders in the context of division, but they aren’t used to thinking about computing a remainder as a separate operation, and they certainly don’t recognize % as a symbol for it. Even experienced programmers often mentally “pattern-match” this sort of expression to recognize it as a divisibility test instead of thinking through the arithmetic of it.

Encouraging the use of isMultiple(of:) (and !isMultiple(of:)) serves to counter bugs around negative remainders.

It has some potential for better performance, especially when applied to large integers. In this case, this impact would probably not be a sufficient justification on its own.

Joe Groff (tweet):

A related common operation, the one I want to focus on here, is to test whether a number is an exact multiple of another, using the remainder operator[…]clang and gcc leverage the same division-into-multiplication trick to optimize this operation, first performing the division via multiplication, then multiplying by the divisor and comparing the result to see if the result matches[…]


Can we do better? It turns out we can, using some tricks with modular arithmetic. Integer arithmetic in a 32- or 64-bit CPU register wraps if it overflows, effectively implementing the integers modulo 2³² or 2⁶⁴. An interesting property of integers modulo 2ⁿ is that every odd number has a modular inverse, which is another number it can be multiplied with modulo 2ⁿ to produce 1.

Previously: Dividing by Multiplying.

HP Leaves Mac Users Vulnerable to Fax Hacks

Saheli Roy Choudhury:

Researchers at Nasdaq-listed Check Point Software Technologies said that fax machines — which still reside in many offices — have serious security flaws. Those vulnerabilities could potentially allow an attacker to steal sensitive files through a company’s network using just a phone line and a fax number.

In a report released on Sunday, Check Point researchers showed how they were able to exploit security flaws present in a Hewlett Packard all-in-one printer. Standalone fax machines are a rarity in companies today, but the fax function is still present in commonplace all-in-one printers.

They faxed over lines of malicious code disguised as an image file to the printer, relying on the fact that no one usually checks the contents received over a fax. The file was decoded and stored in the printer’s memory, which allowed the researchers to take over the machine. From there, they were able to infiltrate the entire computer network to which the printer was connected.

Joshua Long:

Oftentimes when HP releases firmware updates for printers and multifunction devices, the company only makes the firmware available in the form of an EXE file — a Windows application. In spite of the severity of the Faxploit bugs, HP has not made an exception to this unfortunate practice.

Of the more than 150 affected models for which HP released firmware updates, approximately one quarter of them do not have a Mac-compatible firmware update installer available to download through HP’s support site.

NetNewsWire Comes Home

George Dick:

Since acquiring NetNewsWire from Newsgator in 2011, we’ve invested a great deal in the continued development and support of the product suite including the addition of a free sync service. Unfortunately, the ongoing cost of support and feature development for these products require more dedicated resources than we are able to provide.

With that in mind, today we are removing all versions of the app from sale. We’ll continue to run the sync service for another 60 days, then take it offline at the end of October.

We would also like to announce that the NetNewsWire brand will be returning to its original creator, Brent Simmons.

Brent Simmons:

You might reasonably wonder if nevertheless [Black Pixel] asked for some large amount of money. There was no charge. That’s what I mean by “incredible generosity.”


You probably know that I’ve been working on a free and open source reader named Evergreen. Evergreen 1.0 will be renamed NetNewsWire 5.0 — in other words, I’ve been working on NetNewsWire 5.0 all this time without knowing it!

It will remain free and open source, and it will remain my side project.

Classy move by Black Pixel, and it’s great to have Simmons working on NetNewsWire again after all these years.

Previously: The State of RSS on the Mac, Evergreen Mac Feed Reader, The Story of NetNewsWire.

Update (2018-09-03): See also: Hacker News.

Brent Simmons:

NetNewsWire Lite 4.0 was the last version I shipped before the sale to Black Pixel, back in 2011. It was a free app on the Mac App Store.

I put the source up on GitHub.

Brent Simmons:

If you’d like to run it, go to the NetNewsWire site and download the latest build.

Brent Simmons:

My goal used to be to make NetNewsWire a great Mac app with lots of paying users. Secondary goals were to promote reading and writing on the web, the blogosphere, and RSS and open web standards.

My goal now is to make NetNewsWire a great Mac app with lots of users. Other, no-less-important, goals are to:

  • Promote healthier news-reading via the open web and RSS
  • Promote native Mac app development by providing a good example and by making the code open source

(Yes, I’m strongly considering an iOS version, but I’m concentrating on the Mac app first.)

Update (2018-09-05): Daniel Jalkut:

Over the years I considered other news readers such as Reeder (which is free for a limited time, by the way), but none of them scratched that NetNewsWire 3 itch. I rely upon some arcane features of the app including “scripted feeds,” which allow me for example to run Python scripts on my Mac that connect to Twitter and generate RSS feeds from search results. That’s not possible in most feed readers.

I used to fantasize about getting access to the NetNewsWire 3 source code and sprucing it up. I wondered how things might have turned out differently if, in addition to acquiring MarsEdit from NewsGator, I had acquired both? I can’t say I would have done a better job than Black Pixel, but I would have preserved the features I care about, and that Clippings folder icon would be the right size!

Brent Simmons:

I was considering publishing the source on GitHub and/or making a 3.4 build that strips out the Esellerate and Google Reader syncing parts.

So I sent the code to Daniel Jalkut, who quickly hacked at it and got it running and sent it back to me.

And then I ran it too — and quickly realized a few things[…]

Update (2018-09-08): NetNewsWire:

Before anyone ever saw a copy, NetNewsWire was called AquaReader. It was renamed to NetNewsWire not long after.

Back in those early days of OS X it was pretty common to put the word “Aqua” or “Cocoa” in your Mac app’s name.


Before NetNewsWire 1.0 shipped, it went through a couple different app icons. In those days, globe icons were very common.

Update (2018-09-10): NetNewsWire:

Here’s a screenshot of the blog editor in NetNewsWire 1.x, which was later split out into a separate app: MarsEdit.


This is what the Combined View looked like in NetNewsWire 1.x.

This was before WebKit existed — HTML display was done by some NSAttributedString method which could handle basic HTML formatting.

Update (2018-09-13): Brent Simmons:

NetNewsWire 1.x included an outliner — a single-document notepad for storing thoughts, links, RSS articles, and so on.