User Profile

This is on an M1 MacBook Pro running 11.1b1. I installed an Extension from Rogue Amoeba to support their App Suite. Boot into recovery to set system policy to allow user permission of extensions Reboot and install extension Allow Extension in Preferences > Security panel Allow rebuild and restart. It comes up with an endless loop of failure due to an Extension from Apple Inc. ! The Rogue Amoeba extension loads fine. Any ideas?

We are using USB 1.1 and USB-C/USB2 protocol sensors over the HID protocol. These work great on all current devices including the DTK using adapters, where necessary. I see a lot of issues on the new MacBook M1. Only a few adapters from USB-A to the USB-C/T3 port work. Some docks like Hyper Drive do not. The USB-C sensors is recognized but cannot transmit data. This devices has been tested on all Macs and a lot of Windows laptops and works on Android OTG, too. Anybody else seeing issue with USB2 and 1.1? It looks like the drivers are not ready for prime time. This all works perfectly on the DTK.

We have updated instruction in our product to allow for the removal of the admin requirement for "Allow"ing third party signed KEXTs based on the latest DP changes.I have stepped through the procedure on a test bed and have to say that for the average user, this is just as confusing as before. The subtlety of having the "Allow" button enabled will cause a congitive dissonance for people also seeing the Admin lock icon at the bottom.We have descriptive dialogs and open the Security and Privacy panel for our users, but why is this necessary? We cannot control the layering of the dialogs, some confusion will be unavoidable. And we cannot directly detect the cause of a potential failure of loading in the app without elevating to admin.I understand the objective, but has this been really worked through by somebody with expertise in user experience?Why do we have a warning dialog that does not immediately allow people to approve this? This was designed for engineers and IT people, not average users.

I finally upgraded my mid 2012 MacBook Pro Retina running a 1TB OWC SSD using a downloade DP7 installer.The upgrade went perfectly including automatic conversion to APFS retaining 3rd party trim enablement.But it took about 15 hours! I did this overnight, so the knucklebiting time was limited. Previous upgrades and installs on a MacPro were usually < 45min. But there was no APFS migration on that. I had to back up, wipe, reinstall, and restore.If it seems to take forever, let it trundle!Added: based on my router statistics, part of the update is a long and large download from a server as the first part of the update. This is with a full installer resident on the machine.

Subject says it all.

The following was filed as a suggestion in Apple's Bug Reporter. By adding it here, it might fuel ideas. Security is a tough challenge.Input concerning KEXT-CONSENT TN2459As described in TN2459 (kext consent) Apple is introducing a security change that will have a significant negative impact on the user experience. Since our product requires a KEXT, we are very concerned about this. This will lead to disruption in users trying to install and use our applications. In addition, the current recovery method for users not responding properly to the current UI flow will be extremely difficult to support. It might even lead to a reduction in security on many systems by support opting to disable SIP instead of adding a Team ID to the security policy, which requires dictating a complex string to a user. Let's remember that in a typical support situation, users are already flustered and support people are under time pressure.First of all, let me state that I am in full support of increasing system security. I understand that even with signing of KEXTs by authorized developers, KEXTs represent a significant risk as a malware vector. However, I do not think that intervention or decision by the average user can help this issue.In our testing and support experience with tens of thousands of users (our active user base exceeds 250k,) we have found that the majority do not read dialogs, especially if their wording does not make any sense to them. Many users click out of instructional videos, they close screens with tutorials. They do not click on Help buttons. Pro users and technical users tend to be different, but the majority of consumers like Mac because they do not have to know about technical issues.When they see the currently proposed dialog, many of them will not fully understand its meaning and just click ok. I have thought about the wording and cannot think of a way to make it more understandable while retaining brevity. They are not likely to load the Security Preferences panel immediately. If they run into trouble with the app, we can guide them to the Security panel. But they might not use the app for 30 minutes and in that case the reference to "Allow" the extension will be gone!They will call support and the current remedy is a daunting challenge. Very few users will have ever booted into the Recovery Partition. More importantly, these inexperienced users are usually helped via remote screen sharing. This is not possible in recovery mode. They will have to be guided to select the Terminal from the menu and then will be asked to type in a terminal command using a Team ID different from the warning dialog such as spctl kext-consent allow GMTXYZA3F4 (not a real ID)Support will then have to make sure, it was entered correctly by asking the user to type spctl kext-consent listand asking for the correct string to be read back. They will not know, whether this worked correctly until the system is rebooted and folks try to run the app. If an error was made, they need to start over. As I mentioned, I suspect many support people with hold queues will simply ask the customer to type csrutil disableWe would all agree, this is undesirable. We will ask our support folks not to do this, but not everyone will be that disciplined.More important, this is not an Apple Mac experience.Here is my input in order of preference to help this situation:Reevaluate this feature altogether and look at alternatives. I do not think that for the majority of users, their decision to allow a KEXT run will contribute to security. Personally, as a technical person I would like the notification. But most users cannot really make a knowledgeable decision. Alternate solutions to the issue would be proactive revoking of TeamIDs certificate with frequent system updates of root certificates or white listing known good KEXTs, which would require a registry. I would consider going all the way to proactive scanning for signatures of all kinds of malware. With my family I have gone to using BitDefender even on Mac to precent issues arising from social engineering etc. As an engineer and long term Mac user since 1984, this is distasteful, but just realistic. Having it built in would be seamless and not noticeable by users.If you retain KEXT CONSENT, improve the user flow and management functionality. Instead of a separate notification dialog immediately bring up the Security Panel and use it to communicate the issue and allow users to OK in a simple way. Currently using two steps makes it much more confusing and requires locating the correct panel.Consider eliminating the 30 min. timeout altogether. It makes it impossible to recover in case of an error.Consider changing the Security Panel to add a section that lists all 3rd party KEXTs that either have consent (even if inherited from an upgrade) or are disallowed. Changing the state should be done with a simple check mark followed by a confirmation dialog. This has the following advantages:- It allows users and support to easily remedy a problem. - It allows for easily checking on known malware KEXTs without pulling up terminal and doing a kextstat | grep etc.Would love to hear, what other developers are thinking.