The Gatekeeper behavior is specific to running things from Finder (not Terminal), and only if you downloaded it via a browser that sets the com.apple.quarantine xattr.
Two posts from Apple dev support (Cmd+F "eskimo") describe this in more detail.
Two posts from Apple dev support (Cmd+F "eskimo") describe this in more detail.
I don’t know why grand op is downvoted. DoD requirements literally require a timeout setting for screensavers to begin locking. This has caught systems which have a race condition where you can move your mouse quickly and gain desktop access before it locks.
The long term effects come from the required changes to the development security model to remain productive and profitable (took MSFT a few OOB hotfixes and service packs to fix that example above, look when gnome kde xscreensaver etc introduced that feature etc)
I fail to see how this is a race condition rather than how a screensaver is supposed to work?
What defines when a locking screen saver is “locked”? 10m? Or 10m1s? You are making assumptions and that is what DISA spells out. Which forces the OS design to change in subtle ways. Like xattrs on files as great grand op was alluding to.
Does that provide clarity into how development security models evolve over the lifetime of an application?
The article says the described problem isn't limited in this way:
> This is not just for files downloaded from the internet, nor is it only when you launch them via Finder, this is everything. So even if you write a one line shell script and run it in a terminal, you will get a delay!
His site (http://www.quinn.echidna.id.au/Quinn/WWW/) supports its claim “I'm not a great believer in web” :-)