Not what I immediately expected: it doesn't give you the cryptographic identity of the target app, but it does read a lot like a high-quality phishing attack where you get to e.g. issue permissions prompts with the totally specific visual identity of the app that you dropped your binary into. A highly technical user might, if we're very lucky, question why they're being asked for permissions again, but an ordinary user never would, for sure. If Apple is going to attest to identity, they need to make sure it's combinatorially right.
I totally understand why the author would love to see this fixed. But I'd honestly continue to go the other direction, (software freedom), and say that I rather wish that we would instead make this whole architecture less rigid. Apple seem to have looked at Windows Vista era UAC... and taken all the worst parts of it.
I tend to think that if we were to give the user a lot more information: people aren't as dumb as Apple treats them. Absolutely many users just do not care, but I think that making the UX as terse as it is is half of what's doing the damage.
---
Imagine:
A new app downloaded from (signal.org)[1] would like to launch.
The app is Signal by the (signal.org)[2] team, [which MATCHES where you downloaded it from][3].
[Signal and signal.org are extremely popular, having been seen N million times this month][4]
You may wish to check all of this information before launching it, but this is a [COMMON][5] app.
---
[1]: this would be the quarantine attr's source
[2]: this would be from the signing identity – but no need to explain that
[3]: I would literally check this and display the prose
[4]: yes, this involves a bunch of localization strings
[5]: This is where you'd have to decide whether you want to provide an opinion or completely disclaim liability, like Apple has had a tendency to do.
This would leave the door open to incrementally more relaxed versions of this posture, including allowing an unsigned app, or less common apps with more alarming language, up to and including color, to communicate how different that is. Even just a (localized to region) traffic light style appearance would go a long way. I totally acknowledge that, for example, the Chrome folks decided that they have to hide and bury this, because users can't be trusted not to proceed anyway when advised to do so. But this is why I think spelling it out in more detail would go a long way, which Chrome never (competently) did. Even with HTTPS certificates, I'd rather write an EXTREMELY high-quality explainer paragraph to the user about WHAT they're accepting.
hyperhello•12m ago
Instead of replacing the executable, couldn’t it be wrapped and augmented, so it’s just running payload in the background with the original permissions and keychain access? It does seem pretty bad.
tekacs•37m ago
I totally understand why the author would love to see this fixed. But I'd honestly continue to go the other direction, (software freedom), and say that I rather wish that we would instead make this whole architecture less rigid. Apple seem to have looked at Windows Vista era UAC... and taken all the worst parts of it.
I tend to think that if we were to give the user a lot more information: people aren't as dumb as Apple treats them. Absolutely many users just do not care, but I think that making the UX as terse as it is is half of what's doing the damage.
---
Imagine:
---[1]: this would be the quarantine attr's source
[2]: this would be from the signing identity – but no need to explain that
[3]: I would literally check this and display the prose
[4]: yes, this involves a bunch of localization strings
[5]: This is where you'd have to decide whether you want to provide an opinion or completely disclaim liability, like Apple has had a tendency to do.
This would leave the door open to incrementally more relaxed versions of this posture, including allowing an unsigned app, or less common apps with more alarming language, up to and including color, to communicate how different that is. Even just a (localized to region) traffic light style appearance would go a long way. I totally acknowledge that, for example, the Chrome folks decided that they have to hide and bury this, because users can't be trusted not to proceed anyway when advised to do so. But this is why I think spelling it out in more detail would go a long way, which Chrome never (competently) did. Even with HTTPS certificates, I'd rather write an EXTREMELY high-quality explainer paragraph to the user about WHAT they're accepting.