3 ms·

do you imply that an iPhone is not secure ?

by dvhh 10y ago

csydas 10y ago
No they're saying arbitrary code execution on the phone would be insecure, perhaps in a slight misunderstanding of what the article suggests, but true nonetheless. I too am wary of a diagnostic partition/back door as an answer to this conundrum as it seems like it just introduces another vector for attack. We can say "just make it secure" or "don't give it access to do malicious stuff, but the nature of jailbreaks on the iPhone rely on bugs in otherwise innocent functions. Jailbreaks are just exploiting the phone security. The author seems to be of the opinion that there should be a hardware test that doesn't require actual access to the phone, which is probably true -- they likely could just swap the speaker in this case and call it a day. But many of the hardware components are integrated on the iPhone and I'm not sure there's value in a dedicated speaker test device or a limited hardware test device like that. Similarly, quality testing afterwards would best be done before handing it back to the customer; it's pretty lousy service to hand back a fixed device for it to just not work again, and at some point to ensure that you've solved the problem you need to get into the phone. I don't know what the full answer is here since the core problem seems to be Troy doesn't trust Apple. As others have said, you give up your car keys when you get your car repaired. You let the plumber into the house. At some point trust has to be there and people need to be held accountable for violating that trust. Geeksquad violated that trust without real penalties multiple times, so it's a legit fear. But Troy seems really intent on distrusting Apple -- that's fine, but he needs to realize how that's in direct conflict with how support works. Does he insist the same security on his car? (Ie, no keys for the mechanic?). As for a solution, maybe an iPhone onsite imaging tool, some small microboard attached to a raid box that quickly pulls an encrypted image and stores it temporarily on site. The tech can test it on a vanilla and then restore for the client. I don't know if this would violate the iPhone security though being able to restore the image...
- detaro 10y ago
  I read it more as that he does trust Apple (who could remotely update his phone with backdoors, read his iCloud contents or ..., but likely has strict controls in place against this), but he doesn't necessarily trust a random individual Apple employee who has unlimited and unsupervised access to his phone. Especially since there are documented cases of store employees copying photos, less so of Apple actually compromising user data if avoidable.

do you imply that an iPhone is not secure ?

by dvhh 10y ago

do you imply that an iPhone is not secure ?

No they're saying arbitrary code execution on the phone would be insecure, perhaps in a slight misunderstanding of what the article suggests, but true nonetheless. I too am wary of a diagnostic partition/back door as an answer to this conundrum as it seems like it just introduces another vector for attack. We can say "just make it secure" or "don't give it access to do malicious stuff, but the nature of jailbreaks on the iPhone rely on bugs in otherwise innocent functions. Jailbreaks are just exploiting the phone security. The author seems to be of the opinion that there should be a hardware test that doesn't require actual access to the phone, which is probably true -- they likely could just swap the speaker in this case and call it a day. But many of the hardware components are integrated on the iPhone and I'm not sure there's value in a dedicated speaker test device or a limited hardware test device like that. Similarly, quality testing afterwards would best be done before handing it back to the customer; it's pretty lousy service to hand back a fixed device for it to just not work again, and at some point to ensure that you've solved the problem you need to get into the phone. I don't know what the full answer is here since the core problem seems to be Troy doesn't trust Apple. As others have said, you give up your car keys when you get your car repaired. You let the plumber into the house. At some point trust has to be there and people need to be held accountable for violating that trust. Geeksquad violated that trust without real penalties multiple times, so it's a legit fear. But Troy seems really intent on distrusting Apple -- that's fine, but he needs to realize how that's in direct conflict with how support works. Does he insist the same security on his car? (Ie, no keys for the mechanic?). As for a solution, maybe an iPhone onsite imaging tool, some small microboard attached to a raid box that quickly pulls an encrypted image and stores it temporarily on site. The tech can test it on a vanilla and then restore for the client. I don't know if this would violate the iPhone security though being able to restore the image...

detaro 10y ago
I read it more as that he does trust Apple (who could remotely update his phone with backdoors, read his iCloud contents or ..., but likely has strict controls in place against this), but he doesn't necessarily trust a random individual Apple employee who has unlimited and unsupervised access to his phone. Especially since there are documented cases of store employees copying photos, less so of Apple actually compromising user data if avoidable.