Interesting, you’re still paying about $5k an hour from what I can see though. If you want to fly private and can afford it, it’s possibly a good deal.
LittleSnitch 4 can continue to work (with the kext) on Big Sur following this: [1]
LittleSnitch 5 can block all protected MacOS processes by following this: [2]
Murus can use PF and block IPs for Apple services: [3]. This isn't per process, and is really just a UI for the built-in PF process.
If you'd like to block the notarization check, you can block trustd (/usr/libexec/trustd) access to ocsp.apple.com (on both system and user process ownership in LittleSnitch).
Hope this helps. It's really not as bad as you think, there's a few solutions depending how thoroughly you want to block things.
> If you'd like to block the notarization check, you can block trustd (/usr/libexec/trustd) access to ocsp.apple.com
Technically speaking, OCSP and notarization are two different things. The notarization check is actually to https://api.apple-cloudkit.com by /usr/libexec/syspolicyd
I believe you can still block the specific destination IPs with pf using murus if you want, but yes it's quite bothersome.
You can find the full list of apps that bypass it here:
/System/Library/Frameworks/NetworkExtension.framework/Versions/A/Resources/Info.plist under ContentFilterExclusionList.
I disagree with the author. A coding challenge is a good way to judge how a candidate approaches a problem. The ability to walk through what you’re thinking while you’re doing it is a great judge of ability.
It also helps to weed out people who can’t actually program, this comes up annoyingly often.
I agree that having intentional errors in a starter repository is bad though.
You can also have a discussion one how one would approach the problem vs actually doing the coding. The discussion alone would give great insight into how the applicant understands the whole concept, and any potential pitfalls that can be anticipated, etc.
