Secure Kernel Extension Loading is too deterrent (KEXT Deprecation)

Originator:robert.freudenreich
Number:rdar://33025830 Date Originated:
Status:Open Resolved:
Product:macOS + SDK Product Version:10.13 Beta 2
Classification:Enhancement Reproducible:Always
 
Summary:
While the general idea of the new Secure Kernel Extension Loading feature is greatly appreciated, the current implementation in macOS 10.13 Beta 2 seems to overshoot the mark. I am afraid that it is too deterrent for our users and might scare them away from using our application Boxcryptor (https://www.boxcryptor.com).

Boxcryptor uses a derivate of OSXFUSE (https://osxfuse.github.io) in order to create a virtual volume where users can seamlessly and on-the-fly encrypt and decrypt files. OSXFUSE ships with its own kernel extension and is not just used in our product, but in many other popular applications like e.g. ExpanDrive, Lima, Box Drive or Transmit.

My pain points with the current implementation of Secure Kernel Extension Loading as outlined in TN2459 are:

1) The red warning icon in the blocked kernel extension alert and the title "System Extension Blocked" signals a danger to the average user and rather makes him think that macOS prevented a malware from executing. The alert looks too scary and might result in a high abandon rate and even bad reputation for the application.

2) The user experience of having to separately open the System Preferences, navigating to Security & Privacy and then clicking the allow button is too cumbersome and might also significantly increase the abandon rate for the application and the need for guidance and support for the user. Users will get lost and have problems successfully allowing the kernel extension to be loaded. Giving the user the chance to directly accept the kernel extension loading via "Yes / No", "Load / Cancel", etc. buttons or even simply a "Open System Preferences" shortcut button would greatly improve the user experience and reduce friction.

3)  Using only the Subject Common Name field in the messages shown to the user might not be ideal and confusing in some cases, e.g. when the company name differs from the application name. Adding the application name could improve the comprehensibility of the origin for the alert.

Steps to Reproduce:
N/A

Expected Results:
N/A

Observed Results:
N/A

Version:
10.13 Beta 2

Notes:
I would also like to refer to the following links for additional feedback on the current implementation:

https://openradar.appspot.com/32922559
https://forums.developer.apple.com/message/233954#233954

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!