Launching macOS OmniFocus 4 for the first time brings up a warning dialog: “OSUCheckService” differs from previously opened versions. Are you sure you want to open it?. Having unexpected warning dialogs with subjects whose relationship to OF is unknown to me leads me to question if the OF4 has been hacked/compromised/malware/scamware.
If OSUCheckService is a part of OF, how am I suppose to know that?
Oh, and cautious users would probably say no to that dialog. Does that break OF?
OF4 from the Mac App Store. OF3 is also installed. Sonoma 14.2 & 14.2.1. Intel Macs.
I’ve had the warning dialog as well and was also running OF3 alongside OF4 (both were running at that time. OF4 was installed through the Mac App Store but OF3 was installed from the Omni provided installer. That may have been the reason why this warning dialog was triggered. I have since removed OF3 and no longer seen it.
You can use the Activity Monitory in macOS to search for OSUCheckService. You’ll find a process named “com.omnigroup.OmniSoftwareUpdate.OSUCheckService” so it is a part of OmniFocus (with the letters OSU standing for Omni Software Update). Could be a shared software update checker for all Omni software products if going by the name alone.
Since it is a software update checker it would not matter if you click “no”, OmniFocus will still work (and I can confirm because I clicked “no” just to try it) but you would not be able to check for updates.
Thank you @dompelpomp I agree this could be the reason.
But in the end I would expect OmniGroup to mention this in a installation guide or at least follow this forum and give an official statement to this. After all, this is an area in which you should not click lightly and work with assumptions.
You are overreacting and having a rather unrealistic expectation. No need to make it look like the world is ending or that this is a major security issue because it most definitely is not. We are talking about a small bug that can occur in a very specific situation and just a quick glance in Activity Monitor already makes it clear what’s going on. Just report it to Omni via the official way (which is e-mail, this forum is only for user-to-user support).
Also this is not based on assumptions. The naming of the process/file makes it clear what it is and the OS provides ample tooling to inspect the process/file further. That’s what I used to draw the conclusion.
I know you can have a great argument about this. But you can see that the systems are increasingly throwing warnings and pop-ups so that people are starting to ignore them. That wasn’t the idea of security alerts. If someone doesn’t know where to start looking, they would have to invest time and contact support.
There was a very long beta phase, the message is caused by design and reconstructable, so this is guaranteed to be known. I wouldn’t call this unrealistic - first impressions are what matters and something like this is unnecessarily frustrating, especially if there are other problems on top. During such a major product changeover, I would simply have expected some things to be different.
That’s just my opinion and I’m grateful that the community is active - thank you
Sorry for any concern caused about this prompt! I only saw this for the first time last month myself, and so far as I know it was never reported before we shipped the final release.
I believe this alert is new in macOS Sonoma, and I believe it happens when switching between the Mac App Store or TestFlight build and the direct download build. I think the system considers the OSUCheckService to be different because its provenance is different: the Mac App Store and TestFlight downloads have their contents signed by Apple, while the direct downloads from our website are signed by Omni.
None of this came up during the TestFlight because the app was always installed from the same place. (And because it only happens when switching to a new download source on macOS Sonoma, and everybody in the full TestFlight joined before macOS Sonoma existed.)
Now that we know that this is happening and have a (not-well-tested) theory as to why, we can proceed to find a solution (such as giving the OSUCheckService binary we submit to the App Store a different identifier so it’s expected that it will be signed differently).
