Better system permissions onboarding

[lwouis]

The app requires the some checkboxes to be checked by the user in Preferences > Security & Privacy:

• (10.9+) Accessibility
• (10.15+) Screen Recording

These boxes have 2 issues:

• If the user forgets to check the Screen Recording checkbox and tries to launch the app again, they will not be given the OS prompt for permission again, unlike the Accessibility prompt.
• they are not observed, so changes during the app lifetime will not be taken into account

[lwouis]

I tried to play with tccutil (e.g. tccutil reset ScreenCapture com.lwouis.alt-tab-macos). It seems however that this call returns immediately but is actually not processing synchronously. This means that If I do:

• prompt for perm
• reset perm
• prompt for perm

The user may click the 2nd prompt, but not see the app in the list, because (I believe) of some issue with the way tccutil is processed by the OS.

[lwouis]

This issue was mitigated in debug builds targeting local development with 5d771bd.

For production builds targeting end-users, something similar to the above strategies may still be an improvement. The best experience would result from implementing #13.

[lwouis]

Very in-depth article discussing these permissions and the associated UX

[lwouis]

Here is how TeamViewer does it:

Way too much text, but I like the general idea of showing a list and traffic lights. Almost gamifying with the user trying to turn all the lights green.

[mfn]

Almost gamifying

I chuckled at this, but it's a fair observation :)

[lwouis]

I started implementing Accessibility permission observing in: https://github.com/lwouis/alt-tab-macos/tree/accessibility-permission

I observed the Accessibility permission checkbox state, and based on that I start/stop listening to keyboard events. However I realized that this also impact subscribing to process and window accessibility events. The codebase is really is not easy to refactor to handle dynamically stopping/starting listening to these events. The app currently make a model in memory of the state of apps and window around it. If you uncheck the permission, and the app suddently stops tracking things because it is unable to, then the model is going to be broken.

It would take a lot of code and complexity I think to make it that flexible. For now I'll just observe the checkbox, and if someone removes it, it will simply quit AltTab, so we avoid the terrible behavior described in #269 for cheap. The user would then relaunch AltTab, and get prompted to give permission, as on the initial start.

It is not the best onboarding UX, but it is cheap to implement for now.

[mpl]

Hello,

I was about to open another issue to ask a related question, but maybe it is ok in here, as others may end up here after searching in the issues, like I did.
Anyways, here it is: I was a bit worried when I saw that "screen recording" was required as a permission (sounds a bit nefarious, as it seems like the app could capture a lot of private information). So why is i actually needed? Does it completely break the app if I don't allow this permission?

In any case, thank you so much for this project. The inability of the standard macos switcher to be restricted to the apps on the current space has been driving me crazy, since I'm so used to it from years of Linux window managers.

[lwouis]

Hey @mpl! I appreciate you raising concerns regarding the strong permission requirements of AltTab.

AltTab is, from an OS API standpoint, an accessibility app; like a screen-reader is. It queries state of the windows of other apps, and can manipulate them (i.e. focusing them, minimizing them, etc). Another thing it does is display screenshots/thumbnails of these windows in its own UI. This is why it requires the new Catalina permission called Screen Recording. Without it, AltTab wouldn't be able to display thumbnails of other windows. We could imagine a degraded mode where there are no thumbnails if the permission is off. Feel free to open a ticket for that. Personally I think all the value-proposition of AltTab is in its windows thumbnails, but there have been other suggestions to add a preference to hide thumbnails to only show app icon, and/or titles, so that could be combined with the degraded mode here and do a 2-in-1.

On the general topic of security/trust: you can never know if you don't reverse-engineer the app, what the app is truly doing, however, I can still try to convince you of my intent, for what that is worth: I'm doing this app out of wanting to empower others. I have no intention of making any money out of it, and have a very conscious goal of being as non-intrusive as possible. That means I worked hard on the app size, consumption of the user resources (CPU, mem, battery, etc), and user privacy. There is no telemetry or any network call from the app. That one is easily confirmed using an app like Little Snitch. All the source code is visible here on Github, though I understand that few people have time to actually check it. Also it could differ from the actual release .zip. For that last part note that I connected TravisCI to Github, so build logs are public, and thus you can see exactly how the app is built from source. The only thing you can't see are some secrets such as my Apple ID certificate for which I pay Apple $100/year, so that no user gets the Gatekeeper warning when they launch the app for the first time.

Hope that gives some perspective on the permission, and the general initiative of this project 👍

[mpl]

Hey @mpl! I appreciate you raising concerns regarding the strong permission requirements of AltTab.

Thanks for the detailed answer.

AltTab is, from an OS API standpoint, an accessibility app; like a screen-reader is. It queries state of the windows of other apps, and can manipulate them (i.e. focusing them, minimizing them, etc). Another thing it does is display screenshots/thumbnails of these windows in its own UI. This is why it requires the new Catalina permission called Screen Recording. Without it, AltTab wouldn't be able to display thumbnails of other windows. We could imagine a degraded mode where there are no thumbnails if the permission is off. Feel free to open a ticket for that. Personally I think all the value-proposition of AltTab is in its windows thumbnails, but there have been other suggestions to add a preference to hide thumbnails to only show app icon, and/or titles, so that could be combined with the degraded mode here and do a 2-in-1.

That's very interesting. I was expecting the answer to be that the app would be completely broken without the permission. I personally don't care very much about the thumbnails, and if AltTab was not open-source, I would indeed value the option to have the degraded mode so I wouldn't have to trust a potentially shady app.

On the general topic of security/trust: you can never know if you don't reverse-engineer the app, what the app is truly doing, however, I can still try to convince you of my intent, for what that is worth: I'm doing this app out of wanting to empower others. I have no intention of making any money out of it, and have a very conscious goal of being as non-intrusive as possible. That means I worked hard on the app size, consumption of the user resources (CPU, mem, battery, etc), and user privacy. There is no telemetry or any network call from the app. That one is easily confirmed using an app like Little Snitch. All the source code is visible here on Github, though I understand that few people have time to actually check it. Also it could differ from the actual release .zip. For that last part note that I connected TravisCI to Github, so build logs are public, and thus you can see exactly how the app is built from source. The only thing you can't see are some secrets such as my Apple ID certificate for which I pay Apple $100/year, so that no user gets the Gatekeeper warning when they launch the app for the first time.

Sorry, I wasn't questioning your intent or ethics, and I did not mean for you take so much time answering that aspect. As you might have gathered looking at my profile, I'm pretty familiar with the world of open-source myself ;)
I usually give the benefit of the doubt to open-source software (wrt to intent and good intentions), which is why I had already installed the app. I indeed certainly wouldn't do the same as easily with proprietary software.
When puzzled with e.g. the requirement of such a strong permission in an (open-source) software I'd most often wonder about the competency of the devs, but you seem to know what you're doing ;)

Hope that gives some perspective on the permission, and the general initiative of this project 👍

Yes, thanks again! I'm already loving it compared to the default one.

[lwouis]

I implemented this ticket. It looks like this:

It is quite a sophisticated solution as it continuously listens to the permissions, and will handle permissions being removed while the app is still running. That may sound simple, but of course there are no APIs to check the new Catalina permission, so I had to do a mix of heuristic and private APIs.

After the app starts with proper permissions, it will check every 5s that its permissions are still enabled. If someone knows of a better way to check than a Timer, please me know! Currently the timer is 0.1s on the new window shown above, and once the app starts, it goes to 5s checks to not use significant resources on the machine, yet still monitor the permissions to avoid a poor UX if the permissions are removed.

Note that contrary to what Apple tells the user, removing the Screen Recording permission does apply immediatly, and not when the app is quit. This here is simply a lie:

[mfn]

holy.cow.

That could be an app on its own, with that level of sophistication 👀

[lwouis]

Zoom which is backed by God knows how many engineering resources doesn't support removing permission while its open lol