Can we have a privacy toggle so that the Maccy popup window doesnt show up at all on screen recordings and sharings

[adamlahbib]

Before Submitting Your Feature Request

• [x] Check that there isn't already a similar feature request to avoid creating a duplicate.
• [x] I have seen the FAQ.

Problem

No response

Solution

No response

[freebrowser1]

Can be a nicxe idea, but how do blind you select a clipping ?

[weisJ]

It is possible to hide an application window from screen recordings by setting the windows sharingType to .none. You will still be able to see the window yourself.

[adamlahbib]

@p0deje can you check this PR https://github.com/p0deje/Maccy/pull/1130

[p0deje]

merged in 789d2814f7b78b9be28e87b4caaed737e7cc1fcf

[p0deje]

I think we need to iterate on this for a bit.

1. We need to get preview hidden too (#1133 should address this).
2. This now prevents screenshots from capturing Maccy window complete. I am afraid it's going to complicate a lot of bug reports :) I think there should be a way to determine when screen sharing is starting in macOS (https://www.reddit.com/r/swift/comments/1jysl8g/how_does_raycast_detect_that_screen_sharing_is/). When that happens, we can automatically enable private mode and turn it off when sharing stops.

Any thoughts?

[moutella]

About 2. Unfortunately the method posted on reddit does not work, since UIKit is not compatible with macOS. Someone sent an link at the end of the thread that may have some other method, but it's currently down.

I found another app that claims to be able to detect if your screen is being shared, called "Stealthly", but it explicitly states that the Mac App Store version of the app doesn't have this feature, so it's definitely something "not intended" by Apple, which means it's probably not easy to achieve such feature. Raycast also isn't on the Mac App Store.

With that in mind, I think a partial workaround would be:

1. Add a hidden setting that decides whether or not to change the sharingType
2. Set the default to hide Maccy.
3. Then, add in the issue template the commands to change the settings, to help people with bug reports

   defaults write org.p0deje.Maccy privacyMode false # default is true
   

This may be a bit complicated, but I believe most people that are sending bug reports would be able to do this.

This could however lead to someone changing it to false to make the bug report, and forgetting to turn it back to false. I believe a workaround would be to make it obvious to the user that he forgot to set it back, something like this in the footer:

It's really hacky, and would introduce new localization issues, but I don't think translating that should be a priority, since whoever is making a bug report probably understands english.

Another solution would be adding settings like I initially did in #1133, but as you said, that would have to be localized since it would show up to common users.

[moutella]

Nevermind, it's actually pretty easy, but it does use private APIs, which explains why it causes App Store Rejection. I will try to implement it on maccy now

[moutella]

While testing the above solution, I found out that:

1. Sharing or Recording your own screen makes CGSIsScreenWatcherPresent() return true
2. sharingType = .none does hide it from screen share, such as Google Meet, or third party softwares that record the screen, such as OBS
3. However, sharingType = .none does not hide it from native screen recordings, at least not when using the "Screenshot" application, the one that is accessed by pressing ⌘+Shift+5.

Since the title of this issue explicitly mentions screen recordings, I believe this may be seen as a problem. I also think it is, since I commonly use Maccy while recording videos. My current workaround for this issue is using OBS.

[p0deje]

One other possible solution would be to use private APIs to know when the screen is being captured, then use privacySensitive to tell SwiftUI to redact the content. Not sure how reliably to detect all screen recording / screen sharing though.

[p0deje]

You can still access the original MacPaw article at https://web.archive.org/web/20250120210444/https://macpaw.tech/research/is-mac-screen-captured/.

[moutella]

I saw the discussion at #1136 and the comment at #1137 and that changes things a bit. I think the best solution would be to add privacy settings with these two options, redact or hide from screen sharing, warning the user about the limitations with DisplayLink and native screen sharing.

I think having both settings as an option is good, because they have different use cases:

1. Hide from screen sharing is useful for maintaning privacy on meetings and recordings
2. Redacting is good for keeping privacy when on public spaces such as coffees and offices, and will also serve as an limited-but-useful privacy option for people with DisplayLink.

I get that this will add the localization issues, but it seems like a reasonable trade-off, specially since the redaction is kind of agressive and I personally wouldn't enjoy it being the default behavior.

[p0deje]

I agree, it looks like we cannot find a single good option that would make Maccy work in all these cases. Let's add a new checkbox "Hide during screen sharing" to "Advanced" preferences, which is enabled by default if the user does not have a DisplayPort-connected monitor. I am not sure if there is a way to get this information, but I know that the Lunar app somehow shows which connection is used for an external display. There also needs to be a thorough explanation of the feature, saying that the window would not be present on screen shotting/sharing apps, while you can still use it. It also needs to mention that native screen recording would still capture the window and issues with DisplayPort.

I think this would be a good start.

I am not sure about "redacted," though. What do you think about having another checkbox, "Redact unselected copies"? Once enabled, it would hide all contents with the redacted flag except for the currently selected item. The user could still search entries and manually go through them, while preserving the rest of the copies from being exposed. This mode would only be enabled manually (e.g. if user in the office or starts screen recording).

[moutella]

Since Lunar is open source, I decided to take a look on how they do it. Since the user needs to be running DisplayLink Manager all Lunar does is check if the software is running. They use that information in a few places, even to display a warning about missing features when running displaylink. Lunar also has another method to check if a display is virtual, and one of them is checking if "displaylink" is in the display name.

I think checking if the software is open would be enough in our case, since, if the user is running it, more than likely they will connect a displaylink monitor at some point.

There could also be an hidden option to force privacy mode even in a special way for displaylink users, and force the popup to display on an available non-displaylink monitor.

The behavior for the "redacted" feature seems good. I think an option to enable or disable it automatically while connected or not to certain Wi-Fi connections would be nice, but that could come as an later enhancement to the feature.

[moutella]

To avoid making too many PR's in this repo, I made an candidate at https://github.com/moutella/Maccy/pull/1.

It adds the "Hide while screen sharing" in the Advanced preferences, and also enables/disables that option based on whether or not the user has DisplayLink Manager open when Maccy was launched. If it detects DisplayLink Manager, the option is disabled, and the tooltip is enhanced so that the user can understand why it is disabled, and how to enable it back.

Here is how it looks when no DisplayLink is detected

And this is how it looks when it detects DisplayLink Manager

[weisJ]

The ideal solution would be for macOS to support something similar to secureInput in iOS. There it can be used to hide subviews from appearing on screen recordings, while still looking the same to the person using the app.

Sadly it is not available (not even internally, as otherwise https://developer.apple.com/documentation/swiftui/securefield wouldn’t have the indicated limitations). I really hoped Apple would implement it in macOS 26.