Apple plans to update iPhones in-store without opening the boxes(appleinsider.com)
appleinsider.com
Apple plans to update iPhones in-store without opening the boxes
https://appleinsider.com/articles/23/10/15/apple-plans-to-update-iphones-in-store-without-opening-the-boxes
153 comments
Afaik, the last few iPhone generations are in the box upside down (= with charging coils up) and very close to the box lid :).
I was wondering how this could possibly work physically -- that answers my question, thank you!
Its also pretty dreadful. You can literally no longer trust any flat surface you may place your iPhone onto - in the library, at the store, in public, etc.
All it will take is for this mechanism to be cracked, and we have lost.
All it will take is for this mechanism to be cracked, and we have lost.
No. Apple updates are digitally signed by Apple with a key only they possess.
This is also why jailbreaking an iPhone is so difficult. Nobody else has that key, so the best you can do is find a bug in something Apple approved and try to gain root with it.
There hasn’t been one of those in… years… and as for one that will allow an unsigned persistent update? Not since iOS 9. Almost a decade ago. Nobody has found a persistent jailbreak since.
The last true chip exploit, which Apple cannot patch, was with the A10 Fusion seven years ago. It also required a USB cable, a Mac to inject the payload, and you had (and have) to connect the phone to the Mac every time you reboot it because it can’t persist itself.
This is also why jailbreaking an iPhone is so difficult. Nobody else has that key, so the best you can do is find a bug in something Apple approved and try to gain root with it.
There hasn’t been one of those in… years… and as for one that will allow an unsigned persistent update? Not since iOS 9. Almost a decade ago. Nobody has found a persistent jailbreak since.
The last true chip exploit, which Apple cannot patch, was with the A10 Fusion seven years ago. It also required a USB cable, a Mac to inject the payload, and you had (and have) to connect the phone to the Mac every time you reboot it because it can’t persist itself.
It is still however an attack vector.
> signed by Apple with a key only they possess.
Oh, so its okay as long as we trust Apple to tell us when their key is stolen...
Oh, so its okay as long as we trust Apple to tell us when their key is stolen...
Everything secure requires a key of some abstraction.
That’s literally how every secure mobile phone works. Same for Samsung, same for Pixel, same for GrapheneOS.
Presumably this function would be disabled after the phone is unboxed and set up for the first time…
Phones have NFC readers so your statement is already true if you take paranoia to delusional levels.
Phones have NFC readers so your statement is already true if you take paranoia to delusional levels.
That's putting a lot of trust in Apple. What else can they do when the is off.
Whatever they've wanted to since they started shipping the product, the same as every other manufacturer. If "Apple is secretly after me and others" or "I can't trust that Apple is sufficiently secured against a 3rd party turning their devices against me" is your threat vector then owning an Apple (or other's) device has always been problematic for you and does not change with plans of them updating the firmware in store.
Being able to remotely turn it on and push updates is a new problem, and requires strong measures to lock it down.
Why is it fair to assume this is only a concern when Apple publicly announces it if the whole concern is they won't publicly announce misuse? The phones already do things when off now e.g. Find My.
If by remotely, you mean physically touching the device, then one could say that it's remotely turning the device on.
I mean by remotely, what the article means by remotely:
"Consisting of a "pad-like device," store employees place unopened iPhone boxes onto it to trigger an update. The pad wirelessly turns on the iPhone, runs the software update, then turns it off again."
As in without contact with the device.
"Consisting of a "pad-like device," store employees place unopened iPhone boxes onto it to trigger an update. The pad wirelessly turns on the iPhone, runs the software update, then turns it off again."
As in without contact with the device.
But they can already push updates OTA, and presumably this is subject to the same signing
I think your worry is this: this capability means Apple can turn on and install arbitrary software whenever they want.
Wood you be ok if this capability could only be activated at super-closer range (wireless charging range) and only worked on iPhones that have not been activated?
We don’t know if that is how this works, but I would be comfortable with this feature if that’s how it works.
Wood you be ok if this capability could only be activated at super-closer range (wireless charging range) and only worked on iPhones that have not been activated?
We don’t know if that is how this works, but I would be comfortable with this feature if that’s how it works.
Yes
And that's obviously how it works. Maybe it will then enable wifi instead of sending data through wireless charging but that's it. And then it would turn itself off. Still what you can do is what Apple could do before putting it into the box. Again, obviously
I fail to see how this is concerning (to put it politely)
And that's obviously how it works. Maybe it will then enable wifi instead of sending data through wireless charging but that's it. And then it would turn itself off. Still what you can do is what Apple could do before putting it into the box. Again, obviously
I fail to see how this is concerning (to put it politely)
That is how you would like it to work, but we have learned time and time again that "obvious" does not mean all these safeguards are actually implemented or bug free.
So what you get is a mechanism that wirelessly, without any confirmation, modifies the software on your device and "only" requires proximity. That seems like a great angle of attack for malware, surveillance, cracking a stolen phone,... . You are free to believe that apple implemented this perfectly bug free, but I would not be surprised if we get a CVE related to this in a few years.
So what you get is a mechanism that wirelessly, without any confirmation, modifies the software on your device and "only" requires proximity. That seems like a great angle of attack for malware, surveillance, cracking a stolen phone,... . You are free to believe that apple implemented this perfectly bug free, but I would not be surprised if we get a CVE related to this in a few years.
Your worries are valid, but thankfully Apple security architecture is better than your average left-pad enjoyer. Sure, it is possible there will be security implications.
> that wirelessly, without any confirmation, modifies the software on your device and "only" requires proximity
Running an update is different than "modifying the software". It is possible that such an update just wipes everything on the phone as well
> that wirelessly, without any confirmation, modifies the software on your device and "only" requires proximity
Running an update is different than "modifying the software". It is possible that such an update just wipes everything on the phone as well
How would it wipe everything on the phone anyway? There’s nothing on the phone. It’s brand new and in the box.
Apple clearly take security very seriously. There’s no way this would be left enabled after someone sets up the iPhone.
Apple clearly take security very seriously. There’s no way this would be left enabled after someone sets up the iPhone.
Just.. how it is.. with any other device and OEM service..?
I don't get it? What do you think does Samsung do when you send over your device for repair? Ever got asked for a passcode by them?
I don't get it? What do you think does Samsung do when you send over your device for repair? Ever got asked for a passcode by them?
Luckily the post explicitly stated how it is different and you can even read it again.
Yes, and it was moronic. Has nobody here ever heard of DFU mode?
This seems really easy to implement , IMO. Here's a world where this basically already works:
* When an iPhone comes from the factory, it's not really off-off, it's just in standby mode. Probably true to some extent in any case?
* If battery is above 50%, try to connect to a special Apple Store wifi network with a known signature. (Wifi has to have this kind of feature, right?)
* If you're connected, check for updates and apply any that apply.
* Go back to sleep.
Easy peasy. Bonus points if you can wirelessly charge them through the box, but honestly apple stores probably go through enough product it doesn't even matter.
* When an iPhone comes from the factory, it's not really off-off, it's just in standby mode. Probably true to some extent in any case?
* If battery is above 50%, try to connect to a special Apple Store wifi network with a known signature. (Wifi has to have this kind of feature, right?)
* If you're connected, check for updates and apply any that apply.
* Go back to sleep.
Easy peasy. Bonus points if you can wirelessly charge them through the box, but honestly apple stores probably go through enough product it doesn't even matter.
AFAIK it's off-off. Any kind of standby mode that was monitoring WiFi would drain the battery after some number of weeks, and Apple doesn't want consumers to open their box to a phone that won't turn on until it's charged.
And phones can definitely sit around for many months, at the warehouse and the store.
And phones can definitely sit around for many months, at the warehouse and the store.
I walk into an Apple store with my device masquerading as the Apple update endpoint, and update the phones with some arbitrary payload to pwn your device before you even open the box? idk if it's possible, but seems plausible.
Apple might not be willing to give you their private key to sign your updates with.
Surely you have to put a lot of trust in Apple as soon as you buy their product?
I mean you do need to trust them a bit more when they have the capability to remotely install software.
You mean like on almost every laptop or phone sold today with their OTA update support? Whether Apple installs the updates before or after you first start the device doesn't change the risk.
Maybe you don't install any updates over the entire device lifetime? Okay but what if the firmware runs a keylogger? You always need to put a ton of trust into the company.
Maybe you don't install any updates over the entire device lifetime? Okay but what if the firmware runs a keylogger? You always need to put a ton of trust into the company.
Well, maybe they had that capability all along, hmm. I guess you trusted that they didn't?
Well no, I use a phone that I could install an OS on myself.
If your phone vendor can install firmware blobs, you have basically the same problem. But I agree that it’s a problem I wish we didn’t have.
Apple already has the capability to remotely install software on your phone.
Spooky23(1)
Literally everything already, they're authoring and flashing the firmware.
I disagree. The same could be said for client side scanning child pornography. This is about the potential capacity for abuse where there was not capability previously.
Apple owns the firmware.
They could enable 24/7 recording, lie to the OS about what is happening and trickle the data back server-side within harmless iCloud requests. It would be pretty much undetectable.
And the point of CSAM client-side is that it is more secure and private than them doing it server-side.
They could enable 24/7 recording, lie to the OS about what is happening and trickle the data back server-side within harmless iCloud requests. It would be pretty much undetectable.
And the point of CSAM client-side is that it is more secure and private than them doing it server-side.
The difference is there is no not choosing to use client-side scanning. I could choose not to use apple cloud services for photos and therefore not participate in server side scanning. Essentially, client-side scanning assumes everybody's guilty until proven innocent. It's a slippery slope for scanning local content. Today the admirable goal of eliminating child pornography and maybe tomorrow FBI most wanted list, then pretty much anybody in the criminal system. Not to mention the political implications.
You see this as a simple trusting apple because they have complete control over the OS/Hardware. I see this as a culture shift that goes beyond trusting any particular company that fundamentally erodes privacy.
You see this as a simple trusting apple because they have complete control over the OS/Hardware. I see this as a culture shift that goes beyond trusting any particular company that fundamentally erodes privacy.
Apple's plan was to scan only those photos going into iCloud on the client, so that they can send them to the server e2e encrypted. That is strictly better for privacy than scanning them in the cloud, as other providers do.
Of course, they could lie and scan everything, but as others pointed out, they could do that already anyway.
Of course, they could lie and scan everything, but as others pointed out, they could do that already anyway.
They _do_ do that anyway for iCloud. The E2EE support was inherently better, as it significantly reduced the decrypted content exposure to Apple. The uproar over the feature and Apple’s relenting on the implementation resulted in no E2EE as the default. Allegedly advanced data protection does do E2EE for iCloud Photos though. I can understand the good intentions playing out poorly and being ripe for abuse.
Apple confirmed they down scan iCloud for unwanted content, and it's pretty obvious doing that would be a huge privacy risk, and it's very debatable whether that actual risk is worse than the theoretical risk of scope creep in on-device assisted scanning.
> CSAM client-side is that it is more secure and private than them doing it server-side.
What can be more insecure and not at all private than scanning user files using user's computer resources? Server-side scanning is impossible if E2EE.
What can be more insecure and not at all private than scanning user files using user's computer resources? Server-side scanning is impossible if E2EE.
While generally true, battery, storage, and cellular data are not unlimited, so 24/7 surveillance couldn't go undetected for very long — at least not yet.
Wait, what? Client-side scanning is offensive and objectionable, but it has much less potential for abuse. None of us have any idea if and how cloud scanning responds to ad hoc requests from anyone.
As much as I oppose client-side scanning, having a single global hash database makes it much harder for a company to do special favors without anyone knowing.
As much as I oppose client-side scanning, having a single global hash database makes it much harder for a company to do special favors without anyone knowing.
Well, no one has any idea of how ad hoc requests are made to turn on your phone when it's off. Logically, if someone's intentionally turned off their phone they desire it to be off.
You're going to be really unhappy when you hear about IME and PSP.
Or, on the topic of cell phones: baseband firmware.
It's really surprising how people end up making absolutist claims about privacy while demonstrating very little understanding of the threat model posed by modern smartphones.
> It's really surprising how people end up making absolutist claims about privacy while demonstrating very little understanding of the threat model posed by modern smartphones.
Would you mind expanding upon that?
Would you mind expanding upon that?
Consider it this way: your smartphone is an advanced collection of multiple, highly sensitive microphones, cameras, location sensors, accelerometers, etc.
The fact that you have a phone in and of itself is traceable, as cell phone towers maintain records of who, when, and where. At this point, usage of such records is so commonplace by LEO that not having your phone with you when you do something is considered suspicious in and of itself.
The fact that you have a phone in and of itself is traceable, as cell phone towers maintain records of who, when, and where. At this point, usage of such records is so commonplace by LEO that not having your phone with you when you do something is considered suspicious in and of itself.
Applies to all phones, dumb or not: law enforcement sends you a SMS that must never be shown to the user. It answers with data that leads to your precise location. Has been there since forever.
Advocating against Apple force-updating a phone that you haven't bought seems... silly in comparison? Especially as only with an up to date OS, you can be sort of safe against attackers, be it state level sponsored or regular ones.
Advocating against Apple force-updating a phone that you haven't bought seems... silly in comparison? Especially as only with an up to date OS, you can be sort of safe against attackers, be it state level sponsored or regular ones.
If it's actually SMS it wouldn't work in the USA on a phone that doesn't support SMS over LTE (3G shutdown). Such a phone is quite usable with data only.
Does that apply when your phone is off?
"potential for abuse"
As opposed to opening the phone, plugging the cable, doing whatever you want and shrink-wrapping again? (which is easy)
"Oh but it's wireless" It's through the wireless charging mechanism. That makes the whole difference
As opposed to opening the phone, plugging the cable, doing whatever you want and shrink-wrapping again? (which is easy)
"Oh but it's wireless" It's through the wireless charging mechanism. That makes the whole difference
My argument is a bit different than others for why Apple would never do this.
The iPhone is one of the most popular devices on the planet, and Apple is in a very high profile position because of it. The last time they tried doing anything remotely close to sneaky was the slowing down of phones with older batteries which eventually resulted in a class action lawsuit.
Sure Apple could install backdoor software, crapware or whatever else in an update, but their exposure to a class action lawsuit would be insane. Whatever they did would be found out pretty quick by security researchers and....you have class action on your hands that will probably cost the org $100M - $500M.
Apple isn't in the business of being nefarious, their in the business of selling you an iPhone. It's in their best interest to sell you the most secure and best phone possible, because all they want is to sell you an iPhone.
The iPhone is one of the most popular devices on the planet, and Apple is in a very high profile position because of it. The last time they tried doing anything remotely close to sneaky was the slowing down of phones with older batteries which eventually resulted in a class action lawsuit.
Sure Apple could install backdoor software, crapware or whatever else in an update, but their exposure to a class action lawsuit would be insane. Whatever they did would be found out pretty quick by security researchers and....you have class action on your hands that will probably cost the org $100M - $500M.
Apple isn't in the business of being nefarious, their in the business of selling you an iPhone. It's in their best interest to sell you the most secure and best phone possible, because all they want is to sell you an iPhone.
Ah, but you forget the license agreement or definitely the privacy policy that changes with every OS upgrade. By doing forced OS upgrades, Apple is essentially forcing new ToS and privacy policy updates on you too.
> It's in their best interest to sell you the most secure and best phone possible, because all they want is to sell you an iPhone.
No. Apple's best interest is to make money. Apple is a business; they care neither about you or me.
The iPhone is side-product, a cash-cow that can be milked over and over.
No. Apple's best interest is to make money. Apple is a business; they care neither about you or me.
The iPhone is side-product, a cash-cow that can be milked over and over.
Just imagine what they can do when the power is on!
I mean unless you author the software for your own devices we all out trust in all of the companies we purchase from.
Apple also writes iOS, so you already have to trust them to buy and use their phones. I don't really see the difference here.
It's not Apple you have to worry about. It's supply chain attackers whose lives just got easier.
Seems no one's worried by the possibility of fast, low-cost, mass device compromise then.
Buying a computer and using it for daily activities is inherently trusting whoever made that computer.
This, I guess, was a minor disaster with the iPhone 15 launch. I bought one the weekend they launched, and the employee told me "don't upgrade to 17.0.1, it breaks transfering from another device; wait for 17.0.2". By the time I got home 17.0.2 was out, but people that bought this the 2 days before probably had a bad time.
I suppose you could test your patch releases even if it's launch weekend, but having the ability to have a known-good version out of the box is nice.
I suppose you could test your patch releases even if it's launch weekend, but having the ability to have a known-good version out of the box is nice.
I don't see how in box updates helps with this?
Sounds like they shipped with 17.0.0, 17.0.1 was a day one patch and determined to be broken, but wasn't pulled before a fixed update was released.
In this situation, instead of being told not to update and you being able to skip the update and run initial setup on 17.0.0 if 17.0.2 hadn't shipped, they may have already updated the device to 17.0.1, and you would have had to wait. Presumably if it was bad enough, they might not sell you the thing until 17.0.2 was available for them to update it before you got it.
That said, in box upgrades are great to avoid huge patches when you open something that may have been sitting on the shelves for a while, and should help with logistics as well. Apple said they wanted to use more ocean freight rather than air freight for environmental reasons, and it will also likely reduce costs, but as another poster was saying, if you can't put the phones in the box until the final OS is ready, you can't ship the phones until the OS is ready, and ocean freight is slow. Being able to ship the phones and update them after they arrive in the destination at the destination store/distribution warehouse eliminates a pipeline bubble.
Sounds like they shipped with 17.0.0, 17.0.1 was a day one patch and determined to be broken, but wasn't pulled before a fixed update was released.
In this situation, instead of being told not to update and you being able to skip the update and run initial setup on 17.0.0 if 17.0.2 hadn't shipped, they may have already updated the device to 17.0.1, and you would have had to wait. Presumably if it was bad enough, they might not sell you the thing until 17.0.2 was available for them to update it before you got it.
That said, in box upgrades are great to avoid huge patches when you open something that may have been sitting on the shelves for a while, and should help with logistics as well. Apple said they wanted to use more ocean freight rather than air freight for environmental reasons, and it will also likely reduce costs, but as another poster was saying, if you can't put the phones in the box until the final OS is ready, you can't ship the phones until the OS is ready, and ocean freight is slow. Being able to ship the phones and update them after they arrive in the destination at the destination store/distribution warehouse eliminates a pipeline bubble.
AFAIK it was not broken?
The update broke the camera recognition for the code. But you were able to type it in manually.
I got mine on launch. The issue is that people were skipping the update which in some cases caused transferring to fail. I'm not sure how people managed to skip since it's heavily suggested as part of the setup, but maybe people are in a rush.
When you get a new phone you wanna play with it right away. The update can wait until Nighttime
They could even run a test suite on an iPhone before selling to a customer. For customers, it would be quite nice to get a charged, updated, verified iPhone.
Normally when you apply an iOS update, you need to enter your pin, but presumably this isn't necessary if the OS hasn't been setup. I wonder what prevents a malicious actor from doing the same thing, if they know the 'secret handshake'?
You can always clean-install a new iOS update in DFU mode, and in this use case the iPhone isn't configured so preserving any non-existent data isn't necessary. But it also looks like you can always update with data through DFU mode?[1] It doesn't say whether the computer has to be pre-authorized with that iPhone, but it's also DFU mode where authorization matters less, so shrug.
1: https://support.apple.com/en-us/HT201263
1: https://support.apple.com/en-us/HT201263
The signing of the update prevents it.
The signing of an update prevents non-Apple sources to install their software. It doesn't prevent a malicious actor from installing an Apple update. (Suppose a user has a phone with iOS 16 but does not want iOS 17.)
They have an unopened/unsetup phone (I would assume this feature gets disabled once the phone is set up) with iOS 16 that they own, and someone with bad intentions wants to forcibly update it to iOS 17?
I mean, technically there is an attack vector there, but it's oddly specific, and since the attacker needs physical access anyways, you've got other problems (i.e. someone got into your home).
I mean, technically there is an attack vector there, but it's oddly specific, and since the attacker needs physical access anyways, you've got other problems (i.e. someone got into your home).
Of course we have signing in general, but my understanding was that inserting the PIN was introduced after the terrorism case so that Apple could not be compelled to hack someone’s phone ever again. Requiring user input for this sort of installation has seemed to be a core part of their security posture.
Of course, having phones be updated before users use them is also super important. So maybe what’s going on here is something that only works when a phone hasn’t been associated to a user yet.
Of course, having phones be updated before users use them is also super important. So maybe what’s going on here is something that only works when a phone hasn’t been associated to a user yet.
I can’t imagine Apple would leave this enabled once the phone is set up. There’s just no need.
Compromised private keys is not uncommon, and in this case it is even more dangerous because you would normally trust that an iPhone in a shrink-wrapped box bought from an Apple store comes directly from the factory.
Pretty sure if someone publicly compromised TSS to that degree, people in the jailbreaking scene would be bouncing off the walls.
When was the last time a large vendor had an HSM compromised directly? Malicious code signed, sure, but I've never heard of keys being leaked from an internal HSM that the attackers didn't have high levels of access to.
It seems to me the threat model for consumers is the same either way. The box itself doesn't offer any meaningful tamper-evidence, so a sophisticated attacker would just re-shrinkwrap everything if they couldn't update them this way.
It seems to me the threat model for consumers is the same either way. The box itself doesn't offer any meaningful tamper-evidence, so a sophisticated attacker would just re-shrinkwrap everything if they couldn't update them this way.
Brilliant way to pre compromise a phone. The victim will never suspect a sealed box
Maybe an attacker triggers this protocol not to install a malicious update but to bypass FaceID/PIN/TouchID and then they can add whatever spyware they want.
- Trigger update via "special pad"
- Interrupt update process to get access to phone
- Wirelessly transmit spyware onto target's phone
- Trigger update via "special pad"
- Interrupt update process to get access to phone
- Wirelessly transmit spyware onto target's phone
This is for devices before they’re sold. There is no face ID or PIN configured.
https://invisqi.com/blogs/all-about-qi/wireless-charging-at-...
Regular Magsafe can start charging at 40-50mm. Power has to go through a lot of packaging layers. If they make an extra-strong in-store charger cradle to boost that distance, it would be possible to reach the phone, and trigger a power-up session without opening the box.
The power detection chip can take very little energy so everything else (other than maybe power-button-press detector) is in super-dormant mode.
On power bootup, the phones can connect to Apple store wifi (preset in wifi defaults), then use key exchange to authorize wifi. Then they can use mDNS/DNS-SD to scan for an update service running on the store network. If found, they can do a key exchange, then download the update, validate, and install.
The whole time, the custom cradle could also be topping up the phones so when the user opens their box, it's charged and they're happy.
Just a guess. Very clever, if true. Also, eminently doable.
Regular Magsafe can start charging at 40-50mm. Power has to go through a lot of packaging layers. If they make an extra-strong in-store charger cradle to boost that distance, it would be possible to reach the phone, and trigger a power-up session without opening the box.
The power detection chip can take very little energy so everything else (other than maybe power-button-press detector) is in super-dormant mode.
On power bootup, the phones can connect to Apple store wifi (preset in wifi defaults), then use key exchange to authorize wifi. Then they can use mDNS/DNS-SD to scan for an update service running on the store network. If found, they can do a key exchange, then download the update, validate, and install.
The whole time, the custom cradle could also be topping up the phones so when the user opens their box, it's charged and they're happy.
Just a guess. Very clever, if true. Also, eminently doable.
Do you need to power it through the casing? I thought all modern phones come pre-charged from the factory.
They do, but you don’t want to risk a power failure during the update. It’s penalty not totally unrecoverable, but certainly not something you want the customer to open the box to.
It might not be charged enough that they’d want to do it without external power depending on how long that particular box has been sitting on the shelf.
So this means they can make and package iPhones much further in advance. I assume that prior to this, they had to keep all of the manufactured units unboxed and ready to update — until the OS was finalized. Now they can make them months in advance with a placeholder OS, and then update them in-store on release day. Smart!
Apple most likely has a pre-OS firmware that pings a local update server and downloads/flashes the OS when an image is available. That way they don't have a ton of iPhones hanging out on the line waiting for GM.
I'm not sure how they would test for update failures in that situation. I suppose they could have a LOM or something that validates the software is installed, reports back to the mothership, then deletes itself. That would imply that it's part of Apple's secure chain.
I'm not sure how they would test for update failures in that situation. I suppose they could have a LOM or something that validates the software is installed, reports back to the mothership, then deletes itself. That would imply that it's part of Apple's secure chain.
Really great idea. Apple has been relentlessly improving the iPhone upgrade process. Long gone are the days when I’d dread the days it would take to fully set up a new phone.
Surprised at all the praises here. Sure, it's cool tech. Sure, it could cut down on updates users have to do/approve/wait for after unboxing.
But sheeshj, one can't build a phone, install software on it, have it sit on a shelf for a bit, and then work as advertised without updating immediately after purchase? Latest iPhones don't sit on shelves that long, do they?
Yeah, I know how it works these days. Like with AAA game releases where people are downloading GB-sized updates a day after release.
But this isn't something to be proud of! If anything, it shows the sorry state of current-day software development & deployment practices.
Fix the problem. Not the symptoms.
But sheeshj, one can't build a phone, install software on it, have it sit on a shelf for a bit, and then work as advertised without updating immediately after purchase? Latest iPhones don't sit on shelves that long, do they?
Yeah, I know how it works these days. Like with AAA game releases where people are downloading GB-sized updates a day after release.
But this isn't something to be proud of! If anything, it shows the sorry state of current-day software development & deployment practices.
Fix the problem. Not the symptoms.
Look at Apple’s track record. It’s insanely rare that they have a problem that requires a day one emergency update for a new OS. They work fine out of the box in the state they were shipped.
Seems to me this is a solution to the other side of the problem. Were you buy a “brand new“ phone and then immediately have to spend time while downloads the update and installs it because the box sat around a little while and your phone has a newer OS version and won’t transfer until the new phone is updated.
Seems to me this is a solution to the other side of the problem. Were you buy a “brand new“ phone and then immediately have to spend time while downloads the update and installs it because the box sat around a little while and your phone has a newer OS version and won’t transfer until the new phone is updated.
> have it sit on a shelf for a bit
Apple has started transitioning some products to ship by boat rather than by air, so it could be over a month from when the product leaves the factory to when it hits the shelf. Having this kind of update process is a lot more important in that scenario, to the point that Apple probably views this as a prerequisite to using ocean shipping for the iPhone.
Apple has started transitioning some products to ship by boat rather than by air, so it could be over a month from when the product leaves the factory to when it hits the shelf. Having this kind of update process is a lot more important in that scenario, to the point that Apple probably views this as a prerequisite to using ocean shipping for the iPhone.
It's a security issue.
If a critical vulnerability is found while the phone is on the shelf, you go home, turn on your phone, boom it's vulnerable.
If a critical vulnerability is found while the phone is on the shelf, you go home, turn on your phone, boom it's vulnerable.
I don't think the issue is half-baked software. It's the idea that you buy a phone six months out from the last major release, open it up, and boom, it's charged and even has the latest update already installed. No irksome red dot on the Settings app icon. It's a little more "magic" to wow the customer.
Sounds like a new vulnerability route if you can flash the device without access to a port. I’d imagine it’s also in preparation for the removal of the port.
They already have been doing this (in a way).
Apple Watch since Series 7 has had a 60GHz wireless USB transmitter in it that replaced the hidden pogo-pins used for OS recovery and diagnostics in the back of house at Apple Stores. They designed a specific sled that has an Apple Watch charger and the 60GHz macguffins, and then carriers that each model watch rides in on top to align to the charger and the 60Ghz connection.
Ironically, it's also USB-C. https://sci.tea-nifty.com/blog/2022/03/post-eb2dde.html
Apple Watch since Series 7 has had a 60GHz wireless USB transmitter in it that replaced the hidden pogo-pins used for OS recovery and diagnostics in the back of house at Apple Stores. They designed a specific sled that has an Apple Watch charger and the 60GHz macguffins, and then carriers that each model watch rides in on top to align to the charger and the 60Ghz connection.
Ironically, it's also USB-C. https://sci.tea-nifty.com/blog/2022/03/post-eb2dde.html
Just curious why 60 GHz was chosen, any ideas? Avoid interference from other sources? Harder to replicate? FCC approvals?
Seems like a very high frequency, although looks like there is now a WiFi band up there?
Seems like a very high frequency, although looks like there is now a WiFi band up there?
Wireless USB at ~60GHz has (sort of) been a thing for a while for short range comms as a possibility.
One of the largest devices that ever used it was the Essential PH-1 and its snap-on camera module (and some other modules as well); the data was transferred over 60GHz USB while power and alignment was delivered by two pogo pins.
There was also Dell and friends' various efforts with WiGig 60GHz docking stations. https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-wigig
One of the largest devices that ever used it was the Essential PH-1 and its snap-on camera module (and some other modules as well); the data was transferred over 60GHz USB while power and alignment was delivered by two pogo pins.
There was also Dell and friends' various efforts with WiGig 60GHz docking stations. https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-wigig
I have been saying for years the next move for Apple is to ditch the charge port entirely. It makes the phone significantly more secure as well since Cellebrite, elcomsoft, etc rely on the lighting port /usb-c for mobile forensics work.
> Sounds like a new vulnerability route if you can flash the device without access to a port.
Apple already updates iOS over-the-air, no port required.
Apple already updates iOS over-the-air, no port required.
[deleted]
So many questions. Is the update pre-loaded on the "pad" that activates the software update protocol?
If not, then does the pad setup a WiFi connection to the store to remotely download it and then install?
Seems like another attack vector for NSO to exploit and add to their arsenal of government oriented spyware.
If not, then does the pad setup a WiFi connection to the store to remotely download it and then install?
Seems like another attack vector for NSO to exploit and add to their arsenal of government oriented spyware.
I’m guessing the pad hooks up to something like an iPad, and the “update pad” has a Secure Enclave of its own. So probably end to end physical security there
I mean it doesn’t really matter. They could use simple public Wi-Fi that’s unencrypted and it would be fine.
Apple already covers the entire boot process and all the OS updates with digital signatures. They can be absolutely sure that no one has tampered with the download and that it was produced by Apple.
They don’t really need a special iPad serving the update to make it secure.
(of course none of this applies if someone figured out how to break digital signatures, but if they did we’re all screwed anyway)
Apple already covers the entire boot process and all the OS updates with digital signatures. They can be absolutely sure that no one has tampered with the download and that it was produced by Apple.
They don’t really need a special iPad serving the update to make it secure.
(of course none of this applies if someone figured out how to break digital signatures, but if they did we’re all screwed anyway)
Count on the NSA being able to find a way. Poster is right, this is another attack vector. Being new and unopened is no longer even the weak reassurance it once was.
I'm sure there's an attack vector here somewhere.
How can we be assured this can't be done for a phone that is set up, in my pocket? There are too many open security questions from this.
There is nothing right now stopping Apple from having iOS download updates over-the-air and installing them without telling you.
It's not Apple that worries me. They already have god powers over the phone. It's the NSA and other supply-chain attackers who now have a channel to implant devices, at high-speed, en-masse and potentially at low cost.
if phone_initialized:
require_authentication() if phone_initialized and not forced_by_law:
require_authentication()Until the phone is initialized, it seems as if it would be Apples property right?
Wrong. It's yours the moment you pay for it. And there is a supply chain extending from where it is to your front door that just got easier to compromise.
From your parent:
> How can we be assured this can't be done for a phone that is set up, in my pocket?
In that case the phone would already be initialized.
> How can we be assured this can't be done for a phone that is set up, in my pocket?
In that case the phone would already be initialized.
And here I am with a fresh iPhone 13 that I was hoping would come on 15.4.1, but actually came on 16.6.
Staying put, hoping for a jailbreak one day.
Staying put, hoping for a jailbreak one day.
Eww. There are lots of security updates after that. I would absolutely not be rocking an old iOS build.
Not anymore, but I would have put up with the security risks 5-8 years ago when jailbreaking my phone let me do a whole host of things I couldn’t otherwise, the chief of which was to be able to use my phone as a hotspot which my previous plan didn’t allow (since I had the grandfathered plan with truly unlimited data in the age of 2GB data limits).
I was previously on an iPhone 7 that I had happily jailbroken on 14.8.1 (and the 7 didn't get iOS 16 so upgrade options were limited anyway, and iOS 15 jailbreaks are far less optimal on small devices like my 32GB 7).
The biggest thing I miss in the first 24 hours? The way I could monitor my battery's temperature even though for whatever reason Apple in their infinite wisdom has decided people shouldn't be able to monitor their battery temperature directly. That, and the tweak I had that would colorize my notifications based on the app icon.
The biggest thing I miss in the first 24 hours? The way I could monitor my battery's temperature even though for whatever reason Apple in their infinite wisdom has decided people shouldn't be able to monitor their battery temperature directly. That, and the tweak I had that would colorize my notifications based on the app icon.
I'm surprised nobody has replicated the WebP iMessage exploit as a jailbreak yet. I guess the iOS jailbreak community isn't as active as it once was.
Where does that hope come from? Does the iPhone 13 work better with iOS 15 than 16?
Fire hazard, given the recent issues
Which recent issues are you referring to?
Probably the incidents of the iPhone 15 (or was it the pro version) overheating. It has since been patched but still it would be a problem if the phone heats up a lot while in package and can't cool down.
That's one thing I'm concern about. The devices can't dissipate heat while in package.
Does this actually charge the phone wirelessly via Qi/Magsafe in order to do so, or does it rely on the phone being precharged to 80% or however they come from the factory?
And if it does charge wirelessly, does that mean they have to move the phone's position specifically to the bottom of the packaging to be close enough to the charging surface? Or is there some fancy tech that can charge via Qi from a couple inches away?
And if it does charge wirelessly, does that mean they have to move the phone's position specifically to the bottom of the packaging to be close enough to the charging surface? Or is there some fancy tech that can charge via Qi from a couple inches away?
The current set up for new iPhones is that they come face down in the box, with the only thing above them the lid of the box.
So all you would need is a very simple jig that would align the box with the charger when the box is placed faced down.
The iPhone may already be close enough for wireless charging to work, and Apple could certainly use an out of spec charger that will work at a slightly larger distance if necessary.
So all you would need is a very simple jig that would align the box with the charger when the box is placed faced down.
The iPhone may already be close enough for wireless charging to work, and Apple could certainly use an out of spec charger that will work at a slightly larger distance if necessary.
fta
''' Consisting of a "pad-like device," store employees place unopened iPhone boxes onto it to trigger an update. The pad wirelessly turns on the iPhone, runs the software update, then turns it off again. '''
pretty cool !
''' Consisting of a "pad-like device," store employees place unopened iPhone boxes onto it to trigger an update. The pad wirelessly turns on the iPhone, runs the software update, then turns it off again. '''
pretty cool !
Hmm, this seems rife for a supply-chain (or do we need a new term, box-in-store) attack?
It seems like the solution would require employees to put the boxes on pads one by one… That seems to be a tremendous amount of work.
I have not been impressed by the quality of the service in-store (waiting more than an hour for basic requests, like buying an AirTag, within earshot of salespeople chatting about their weekend), but I’m not sure this is going to improve it much.
I have not been impressed by the quality of the service in-store (waiting more than an hour for basic requests, like buying an AirTag, within earshot of salespeople chatting about their weekend), but I’m not sure this is going to improve it much.
> It seems like the solution would require employees to put the boxes on pads one by one… That seems to be a tremendous amount of work.
They also sell those boxes one by one via relative in depth customer interactions.
Setting a box in an automated update device is nothing.
They also sell those boxes one by one via relative in depth customer interactions.
Setting a box in an automated update device is nothing.
You seem to assume that they would update them as they sell them—at the same time. I’m not sure how long the update would take, but I’m assuming longer than many customers would like to wait.
They could easily make the device accept 10 or even 20 devices at a time, with a simple LED on for each indication progress. Just check up once an hour and move done iPhones to the done stack and place todo iPhones in the device. Set it up on route to the toilet or next to the coffee machine and it's next to effortless.
But there would be no clear way to tell which box was done, so you rely on proper inventory—or even when updating, to tell when it’s done, presumably.
I had the same thought, although it's possible it only takes a few seconds on the pad to start the process. There's no way it has to sit there for the whole update. It's quite possible that they have to check in each box individually anyway, so this might not add that much time. And it could outweigh the time cost of helping customers with updates post-purchase (or allow them to manufacture/package devices further in advance of the release candidate being available, which could be even more valuable).
Regarding the in-store experience, I have had similar challenges. I walked in wanting to buy an iPad, and knowing exactly which model I wanted (and that it was in-stock at that store). The employee asked me "if I had an appointment". Since when does one need an appointment to purchase something off the shelf? Crazy.
Regarding the in-store experience, I have had similar challenges. I walked in wanting to buy an iPad, and knowing exactly which model I wanted (and that it was in-stock at that store). The employee asked me "if I had an appointment". Since when does one need an appointment to purchase something off the shelf? Crazy.
We have wireless power with Qi/MagSafe, and at least MagSafe can pass a serial number.
You could use a “magic” charger through the box (assuming it’s laid out right) to charge the phone and tell it to go into update mode. It could look for some predefined WiFi/Bluetooth/whatever to get info and do what it needs to.
Apple already has full security on OS updates, so you couldn’t apply rogue updates without having a way to crack that.
This special mode could easily be disabled the moment someone starts setting up the iPhone, so it would only work on factory fresh (or perhaps wiped) devices to prevent funny business.