The worst part about the current behavior is that it is completely random.  Sometimes it opens at 100%, sometimes at 66.864%, other times at 25%.  If it remembered the last manually set zoom level for that device the issue would mostly go away even without a default level.

This really needs to be addressed.  The transfer speed has gotten way worse over the last year of releases and is absolutely abysmal compared to any other method of transfer.  For anything over 100 megabytes or so I can literally upload a file to an FTP site and then download it on the client way faster than drag/drop through SC. 

You're right, I did miss that particular note.  However, there appears to be a new bug related to this fix that causes more clipboard issues. See: https://www.reddit.com/r/ScreenConnect/comments/1d9nopw/significant_clipboard_bug_in_v241/

Bottom line I don't think it's safe to leave the clipboard sharing on at all (and as you mentioned it can be permanently disabled).  Of course it comes down to various levels of risk management, but even one time forgetting to clear a client clipboard of an important admin password still leaves the sensitive data on the clipboard (even if it doesn't show up in clipboard history).  One thing that should be configurable (or even the default in my opinion) would be to have the client ScreenConnect service clear the clipboard upon disconnection of the host.  Of course, all this could be avoided anyway if we simply had an easy way to assign a keyboard shortcut to the "send clipboard keystrokes".

Given the existence of the clipboard history feature available in Windows this is even more important than I originally thought.  Any modification to a client's clipboard could literally be saved even if you manually clear the clipboard.  Nothing short of actually viewing the clipboard history and removing unwanted entries or completely disabling the clipboard history on the client would prevent potentially sensitive data leakage.  Obviously disabling clipboard history on a client machine is not a viable solution.  So even if we default to a disabled shared clipboard enabling it at all, even for a short period, represents a real security risk.

What we really need is a shortcut to send keystrokes without involving the client-side clipboard at all.  While manually clicking the "send clipboard keystrokes" button in the ScreenConnect interface works fine, there is absolutely no reason to not give ScreenConnect customers the ability to define simple shortcuts for features that are critical to the security of an environment.  Forcing us to waste time by hovering over icons and clicking buttons just doesn't make sense for something that is so important (and such an easy thing to implement).

@SConsulting That's interesting.  Hopefully that means it's already in the works, but likely is just an assumption by Mandiant that they already supported it.  Hopefully it's coming soon.  It really is essential at this point and should take precedence over any other UI enhancements or features.

@SConsulting support for custom variables in headers is a great idea, but it's important to also support the proper parsing of X-Forwarded-For.  It's critical to grab the last X-Forwarded-For header and the rightmost value in the list (if there are multiple IPs).  This would be the most effective at preventing any spoofed value from passing through if you don't have access to a custom header.

See: https://adam-p.ca/blog/2022/03/x-forwarded-for/

As others have stated, ConnectWise needs to seriously up their game when it comes to security.  Support for basic identifying headers is something that should have been standard long ago.  Without this the audit logs are virtually useless for anyone hosting an instance behind a proxy.  It also means that we can't block or allow anything based on IP either.

PLEASE, PLEASE listen to your customers who are trying to help you make the product better.  Now that you have dropped Linux and Mac server support years ago there needs to a consistent push to increase security (and to offer features that customers can use to enhance security even further).

This is NOT resolved with v23.8 (at least for Sonoma 14.2.1).  Pretty much destroys the ability to remotely work on a Mac if you can't reboot without needing manual intervention on the remote side.  I know Apple changes things with different releases but if something as basic as this doesn't work then ScreenConnect just isn't a viable remote access solution for Macs.

Yes, this would be quite useful, as it would essentially allow for the convenience of the "shared clipboard" feature without the security problems of actually sharing a clipboard.  Given the small amount of work that it would take to simply add a new keyboard shortcut, a key combination to "paste" from the host side without actually populating the clipboard on the client side should be a high priority.

Yeah, except they are rapidly increasing prices (at least 10-15% increases every year for the past 4 years) even for the legacy on-premise licensing, so the argument that they are "cheap" compared to other options is gradually going away.  Overall I do still like the product, but the development pace isn't where it should be given the constant cost increases.  In many aspects it seems like ConnectWise has it in maintenance mode which is odd since it appears to be one of their most popular products.