Screen recording permission revisited

[neville]

As I noted in a previous post, I had been having a problem with a stack that uses import snapshot to initialise the dragimage for a drag operation: every time I launched the OxTLite IDE and then started a drag, my Mac (Ventura) popped up a dialog asking for authorisation for screen recording. I could say yes to add OxTLite to the authorised list, or I could deny permission, either way the drag operation went ahead unimpeded (that bit is surely a bug in Ventura) and subsequently worked for that IDE session, but on the next IDE launch it popped up again. Same thing happened with a standalone app created from the stack. But it did not happen if I used the LC IDE, the drag went ahead without any permission dialog.

I attach a little stack which you can use to test if you get this "system dialog from hell" on your Mac - try dragging the red square.

A first I thought the difference lay in the fact that the LC IDE has in its info.plist an entry for

<key>NSScreenRecordingUsageDescription</key>

which is missing from the OxTLite info.plist. The entry really should be there (it is in the OxT DPE plist) but it actually makes no effective difference, I think the entry merely supplies a reason to the user as to why the app is making the request.

A Google search finally pointed me to the solution to making the permission "stick". First I deleted the entries in the System Screen Recording Authorised list for all 4 apps LiveCode, OxtLite, OxT DPE and my standalone. Next I launched each app in turn and attempted the stack drag operation: in every case the os did ask for permission as expected on the first drag. So Add each app to the system list. Now turn OFF permission, and Quit the app ( the Google correspondent recommended Force Quit). Now turn permission back ON, and relaunch the app. In each case I no longer get the permission dialog even after relaunching the app or rebooting the Mac, so the permission is sticking - so far anyway. It is evident that it is a further Ventura, or maybe earlier, os bug. I don't know if it is fixed in Sonoma because I haven't dared to install Sonoma in case OxTLite breaks (can someone reassure me on this because the forum posts have me confused as to whether or not is now OK to use Sonoma? and the next os?)

In the course of this investigation, I came across two minor issues...

1. Every time I launch the latest OxTLite I get a dialog about "Refactor" now being a feature. Thank you, got the message, now could it please go away, never to be seen again?

2. When I actually add OxTLite to the Screen Recording Permissions list, it appears as "LiveCode 10.0.0 (dp)" !!! Whereas OxT DPE appears correctly as "OpenXTalk 1.963 1rc3". My guess is there is an incorrect legacy entry in the info.plist, possibly

<key>CFBundleSignature</key>
<string>Revo</string>

[tperry2x]

It's probably identifiying itself as LC still because it probably shares the same plist info (or majority of it). But there's no clear guide on how all of it should actually be formatted. Besides, editing it at all breaks codesigning again, so... not sure what to tell you. I did want someone to pick up mac development, and that's still the case.

[neville]

The attachment got lost

[tperry2x]

Edit: have modified and moved the post that was here, as it joins up nicely with this one.

My ill-feeling towards Apple at the moment, is only because I've spent most of yesterday evening - and into the early hours, going through countless errors that just shouldn't be there. But I'll continue this in the post I've linked to above.

[OpenXTalkPaul]

It's probably identifiying itself as LC still because it probably shares the same plist info (or majority of it). But there's no clear guide on how all of it should actually be formatted. Besides, editing it at all breaks codesigning again, so... not sure what to tell you. I did want someone to pick up mac development, and that's still the case.

Yeah I'm pretty sure you have to re-sign OXT Lite, which I did for OXT DPE. But first I had to strip the previous signature from the binary, then resign. I also added in as many info.plist keys as I though were appropriate going though a list, which I think was on Apple's dev docs site, but they're also in a pop-up menu somewhere in XCode which can be used to edit info.plist keys.

I'm not sure if it's a bug in the Engine or in macOS (I know this happens in mac OS 11 BigSur too), but the fix for repeating permission request on relaunch does seem to be delete the app from the list in System preferences and then let it re-add next time. This can happens with the pixel color sampler too, there is a work around for that (I forget what it was). Also I think if you export or import (I forget which) a snap-shot into a variable it doesn't trigger the permissions request (which makes me think its a bug in the engine, because it probably should).

[tperry2x]

think if you export or import (I forget which) a snap-shot into a variable it doesn't trigger the permissions request (which makes me think its a bug in the engine, because it probably should).

Yes, I think I encountered that one (tries to find previous post) - it was when exporting a snapshot. I'd not given it permission but it did it anyway.

I would agree that the plist editing, breaking codesigning is a real PITA.

We did share the same plist identifier for a while, but then I had codesigning issues and issues with it constantly asking for permissions as soon as the IDE was launched. I understand the problem, but not the solution. That's the theme with MacOS for me now.

[OpenXTalkPaul]

Neville has a good point that standalones are separate binaries that also need the same treatment for the info.plist (they're in the 'runtimes' folder), I think they're already devoid of a code-signature (I think Standalone Builder signs them 'ad-hoc' / 'For Development', like AppleScript does). However one might consider editing of the info.plist a problem for the standalone app's author, but it might be good to offer a pop-up list of several alternative pre-made info.plist templates in the Standalone Builder tab for mac. IIRC, the way it works currently is info from that tab gets merged into a template info.plist in the handler that does the mac standalone building.

Right now my mac laptop is out of commission, but I think I might be repairing that soon (I have an eBay gift card ). I'm currently focusing on Linux stuff (on an even older laptop).

[tperry2x]

..it might be good to offer a pop-up list of several alternative pre-made info.plist templates in the Standalone Builder tab for mac. IIRC, the way it works currently is info from that tab gets merged into a template info.plist in the handler that does the mac standalone building....

That was kind of my thinking - adding all these buttons to the plist section in the standalone builder, but writing the plist directly doesn't work? - I know you advised against that method.

I will concur with Neville when he says the whole plist thing is a nightmare for developers. I'd also second your comment that codesigning is ALSO a nightmare and I don't buy Apple's rhetoric that it's to supposedly make us more secure either. But ultimately, there's nothing I can do about it by design, so that leaves the option of passing mac engine development to someone else. (Someone who does understand all these hoops to jump through).

All I want is a working app, one that actually compiles - and has all the Apple required demands pre-ticked. Whack that in a DMG and I'll make it part of the OXT Lite package forever more (and NEVER touch the plist again in my lifetime).

I'd rather focus on the IDE than try to bend over backwards to Apple's demands (none of which are clear in the first place).

[OpenXTalkPaul]

I'd rather focus on the IDE than try to bend over backwards to Apple's demands (none of which are clear in the first place).

The info.plist in app packages thing is at least as old as Mac OS X, probably as old as NeXT ('.plist' definitely came from NeXT) but Apple has added a lot of security related keys to it since they made those iOS, tvOS.iPadOS, etc. spin-off OSes (which also use .app bundles with .plists).

Still there are some useful keys that can be set, even if your app is only targeting 10.6 SnowLeo. For example you can easily have your app behave like a 'background app' by simply setting that presentation key, the app will then not show up in the Dock when it's running (perfect for a System 'Status Menu' applet).

There are also keys related to 'sandboxing', and macOS will make an app cache sort of 'container'' for your app, without that your app cannot do the 'restore open windows' after something like a forced reboot in order to restore the users session.

If you strip the code-signing off of the binary executable, that affects the way permissions requests get triggered.
I believe this binary in the IDE repo has no code-signature at all (click 'view raw' to download just this binary):
https://github.com/OpenXTalk-org/OpenXt ... -Community
The one here has been signed by me:
https://github.com/OpenXTalk-org/OpenXt ... Signed.zip

Also when you code-sign (or resign) there can be a 'provisioning' file that can be added to the signing command-line, that also affects permission requests on newer macOS. That has options similar to the info.plist, and in some cases an app must have both things set correctly for a feature to work. IMO It's just too many different things to worry about in order to comply.

Clearly Apple doesn't really care about its users security since they've been caught red-handed secretly recording users conversations (they should owe me $100 of that class action $95 million settlement money).

[neville]

All I want is a working app, one that actually compiles - and has all the Apple required demands pre-ticked. Whack that in a DMG and I'll make it part of the OXT Lite package forever more (and NEVER touch the plist again in my lifetime).

I'd rather focus on the IDE than try to bend over backwards to Apple's demands (none of which are clear in the first place).

Hear hear! And is it not time for both you and Paul to stop spending your valuable time on this compile/codesign problem, which is just causing you frustration and despair? And I don't mean give up, the rest of us in the OxT community are frustrated and desperately want a solution, and a clear road ahead. If there is no-one among us who will give up their time to take it on then surely there are those among us who would offer some money to get it done. What I am suggesting is that it is time employ a professional Mac developer to bring the engine code to state where

. it can be compiled for at least all current Mac architectures on a single Mac with a single copy of Xcode
. codesigning sorted out
. documented so that future engine updates, architectures, extensions, codesigning, IDE development, merging of the DPE/Lite forks, whatever, can be managed by "the team" - and hopefully future recruits to "the team"

Surely this wouldn't involve a huge number of hours for someone who does it for a living; if it is beyond a professional to do it in a reasonable time then you two really are taking on an impossible task! Get a quote, and let's see if it can be crowd-funded.

[does the Windows side needs a similar infusion of expertise?]

[tperry2x]

There might be something on the distant horizon regarding the top part of your post. I will have to wait and see.

[does the Windows side needs a similar infusion of expertise?]

I think the Windows side is okay, it doesn't suffer from the issues MacOS does - and nor does linux for the most part (although Paul is working on getting the Browser working again). Video player reliability in linux would be nice to sort out too. To bring it up to par with the Windows version. That's probably a rewrite of the player object.

This is where I am, bugs wise - but please let me know if you know of other issues. I think the windows build is the most complete regarding compatibility and working features. That's my observation. Please let me know if I need to add anything.

[tperry2x]

I'm not sure if it's a bug in the Engine or in macOS (I know this happens in mac OS 11 BigSur too), but the fix for repeating permission request on relaunch does seem to be delete the app from the list in System preferences and then let it re-add next time.

I would be inclined to think this permissions request dialog is an incompatibility with not only the IDE (so not the plist possibly?) as it also affects standalones (which of course I haven't modded the plists for).
I get errant permissions dialogs on standalones that are run on Sonoma. Please see here (to tie these posts together).

[richmond62]

Slightly off-topic, but I did run OXT DPE and LITE on MacOS Sonoma, and now run them on Sequoia without any problems.

I must be one of the happiest campers on the planet as I have never had any of these 'funny' questions on importing or exporting snapshots (something I do on an almost daily basis), on Monterey or Sequoia.

[neville]

Slightly off-topic, but I did run OXT DPE and LITE on MacOS Sonoma, and now run them on Sequoia without any problems.

Thanks Richmond, that's what I needed to now. I was falling a generation behind...