The gotcha is “I gave it permission, then revoked permission in the UI, but it still has permission.”

swiftcoder 4 hours ago | parent | next [-]

That's not quite it either. It's more along the lines of "I revoked access via one mechanism, then granted it via a different mechanism, and the setting UI for the first mechanism doesn't reflect the second action".

There's no privilege escalation here, but there is a misleading privacy settings UI, which offers no obvious way to audit/revoke permissions in the second case

▲

lloeki 4 hours ago | parent [-]

I think the issue is more like:

- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism.

- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism whose permission survives the action context that triggered the file picker (e.g "pick a folder to do action A" also magically imbues similarly gated actions B C D and Z with access to that folder, possibly non-interactively even).

- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism whose permission propagates to an action gated by the first mechanism, a first mechanism for which "Yes" means yes but "No" means "Maybe, depending on past unrelated actions that triggered an unrelated permission mechanism"

	▲	dmdeller 3 hours ago \| parent [-]
		Good analysis. This is a result of trying to retrofit a series of tighter security measures on top of a system that was not originally designed for them, in a way that is both understandable to users but also doesn't break back-compat with APIs (and therefore a lot of existing third-party apps that are seldom updated) too badly. I'm not saying Apple did a perfect job here, but it's a hard problem. Yes, the problem could probably be "solved" by adding more UI, but "more UI" is not always a good solution. The more UI that exists, the less likely the user is to successfully navigate it. On the other hand, adding additional complexity to an existing UI is also fraught with potential for new bugs and edge cases. Again, not defending the status quo, but I can see how it might have ended up like this. This is worth spending more time on trying to improve, and perhaps it is reasonable to expect better from an almost-$4tn company. But at the same time, a potential solution is far from easy or obvious, and there is a risk of making things worse if not done with an extreme level of thought and consideration. (Alternate pessimistic take: A large number of users don't care or read anything, they just click "allow" on anything that gets in their way. A smaller set of users are terrified and disgusted by repeated invasions of the privacy and click "deny" on everything. None of these implementations are doing any good for either group. The allow/deny design pattern is badly broken and in need of rethinking.)

▲

wtallis 4 hours ago | parent | prev [-]

Not quite. The steps are revoking permission in the UI (which works as expected), then implicitly granting permission in a way that the UI does not reflect but quietly persists.