1. 22

  2. 4

    I can’t up vote this based on the color scheme alone.

    1. 3

      It’s already more readable than majority of the websites I see these days:

      • Good contrast
      • Readable font, not thin and not too small
      • Reasonable line-height (not crammed vertically)
      • Reasonable line width
      1. 2

        I was skeptical of your comment, until I clicked the link.

        And the color settings are marked !important so you can’t even override them very easily. Just why?

        1. 1

          Just because…

          main { background-color: #fff !important; opacity: 1; padding: 2rem; box-sizing: border-box; }

        2. 1

          Nice website, good information and stuff.

          1. 1

            I wonder how kext load verification will work in practice. Since most of the time you want to load a kext (because if an application uses a kext then it has a good reason to do it, at least it should), you will need to click OK. And since you will need to click OK 99.9% of the time, like in Windows UAC, this “confirmation” dialog box will only increase UI noise, resulting in users clicking OK because it needs to be done anyway.

            Maybe it would be better to design some additional framework that will give additional privileges and would not require a kext. Like filesystem control callbacks for access control of files and executables, port i/o communication with devices, etc. Linux has it all in usermode, so it’s possible to make it working.

            1. 3

              Kext installation on a Mac is a very rare event, most Macs would have no custom kexts (I think? I guess we’ll find out when High Sierra comes out), and for most people installing or updating a kext is a very rare event. I don’t see a big issue in adding more friction to this process in exchange for higher security. Allowing kexts will happen in the same way that you allow apps to have Accessibility permissions. You can see more info on this on a blog post about the Kextpocalypse and TN2459.

              Maybe it would be better to design some additional framework [… that] would not require a kext.

              That’s what they are doing over time. See for example Network Extension Framework for VPNs and networking apps. Another example is I/O Kit which provides an interface for communicating with USB and FireWire devices from user space. A third example is Audio Unit Extensions, where Audio Units can now run in a separate process so if they crash they don’t take down the host. A fourth example is the Hypervisor Framework which lets developers build sandboxed (!) virtualisation apps without kernel extensions. Here’s some of Apple’s alternative suggestions instead of using Kexts.

              Apple has been slowly but steadily moving more and more away from kernel extensions, adding more restrictions on them, and also (hopefully) providing good alternate solutions.

              1. 2

                A kext most of the time does nothing without its companion usermode application. At the same time, an application often will be incomplete without its companion kext. So I don’t really see the reason why the user should be given a choice related to installing the kext. I mean, maybe they should show a choice before installation of the whole product. Something in the lines of: “This product uses a kext, do you want to install it?”

                The “Kextpocalypse” blog entry you’ve pasted has a nice list of impacted software. Antivirus, virtualization, softwate that comes with hardware, dropbox and similar. On my Mac I have 2 of them (antivirus and virtualization). Sure, todo lists, text editors and games should not have a kext, but sometimes more complicated system software is impossible to create without a kext. Best thing is that some of those impacted applications are meant for non-technical users, like Antivirus. How should a non-technical user know when to unblock a kernel extension and when to leave it alone? When you install those applications, but you won’t install their kexts, you will have to uninstall them because they won’t work. I think it’s a waste of time for the user and the developer and this feature is for marketing only (“hey, we have security!”).

                1. 2

                  It is better though because Angry Birds/Minecraft are less likely to install a key logger. Even for anti virus if you want to you can pick one that doesn’t include a kext.

                  When I created an app + kext a few years ago the app checked if the kext was installed, offered to install it (Requiring elevation) and kept offering to install it until you either successfully installed it or exited the application.