> You come off as making an ad hominem attack, saying that this information is trivial and if the replier can’t find it then they shouldn’t be commenting on the subject.
It’s not an ad hominem. The commenter made a false assertion about how the mechanism works, which is easily checked.
I’ve pointed to where they can check it. The App Store rules, and apples tech docs. There are also other articles with background.
> If it is true that iOS’s permission model is done on the App Store level and not the OS level, which I doubt by the way,
So you don’t know how this works.
> then that is a flaw on Apple’s part and should be fixed. Otherwise we are relying on arbitrary App Store rules to protect our privacy and security,
That’s exactly what many of the App Store rules are for.
> instead of baked in constructs in the OS.
They don’t rely on the App Store rules ‘instead’. They rely on them in conjunction.
It’s not as easy as you think to rely on baked in constructs in the OS.
A trivial example is that such constructs cannot detect text that lies to the user about why a permission is granted.
Another example is that such constructs can’t prevent an app from communicating with a fingerprinting service or using a
These have to be done by policy.
> I’m skeptical that Apple would do something so shortsighted.
Not really sure what to make of this comment, since you don’t present an accurate model of what Apple is actually ‘doing’.
It’s not an ad hominem. The commenter made a false assertion about how the mechanism works, which is easily checked.
I’ve pointed to where they can check it. The App Store rules, and apples tech docs. There are also other articles with background.
> If it is true that iOS’s permission model is done on the App Store level and not the OS level, which I doubt by the way,
So you don’t know how this works.
> then that is a flaw on Apple’s part and should be fixed. Otherwise we are relying on arbitrary App Store rules to protect our privacy and security,
That’s exactly what many of the App Store rules are for.
> instead of baked in constructs in the OS.
They don’t rely on the App Store rules ‘instead’. They rely on them in conjunction.
It’s not as easy as you think to rely on baked in constructs in the OS.
A trivial example is that such constructs cannot detect text that lies to the user about why a permission is granted.
Another example is that such constructs can’t prevent an app from communicating with a fingerprinting service or using a
These have to be done by policy.
> I’m skeptical that Apple would do something so shortsighted.
Not really sure what to make of this comment, since you don’t present an accurate model of what Apple is actually ‘doing’.