Slashdot Mirror
Apple May Be Breaking the Law With Policy On iPhone Unlocks
an anonymous reader writes "Apple's recent decision to void warranties for folks that unlocked their iPhones may wind them up in legal hot water. The site Phone News points out that Apple appears to have broken a key warranty law relevant to SIM unlocks. The Magnuson-Moss Warranty Act, a law decades old, would seem to prevent Apple from voiding warranties in the way it is threatening to do with the iPhone, or so the site argues. 'The Magnuson-Moss Warranty Act states that Apple cannot void a warranty for a product with third-party enhancements or modifications to their product. The only exception to this rule is if Apple can determine that the modification or enhancement is responsible [for] damaging the product in question ... The legal [questions are]: Is the SIM Unlock process that has become mainstream doing damage to iPhone? And, also, is Apple designing future software updates to do damage to iPhone when said SIM Unlock code is present?'"
...from a few days ago is a better lithmus test for this act, don't you think?
Maybe they didn't tell their developers to find a way to cause hacked iPhones to stop functioning. But I doubt that when one of their developers said at a meeting, "...and this update will cause unlocked iPhones to stop functioning..." they thought anything other than, "Good!"
Palm trees and 8
Except your statement assumes that Apple hacked a few iPods into the exact same state as all the hacked iPhones and already ran a patch to see what would happen.
My feeling is why waste that time and moeny? THey will build a patch that will work with a non hacked iPhone 100%. They won't spend a single dime testing it on a hacked one (why should they the ROI on that is a negative). Simply say we can;t guarantee what it will do on a system with a changed state not done by Apple.
From what some posters are posting on here (not the parent just what I have read) is that Apple should somehow make sure the patch will work with every combination of a hacked iPhone. Hmm wonder what that would cost.
Who said it's mainstream? I know of no one that has actualy unlocked their iphone.
Or can you demonstrate a legitimate, technical need for that hash to be there?
Palm trees and 8
"Except your statement assumes that Apple hacked a few iPods into the exact same state as all the hacked iPhones and already ran a patch to see what would happen."
IF you think they haven't already, I'd have to say you are barking mad.
"My feeling is why waste that time and moeny?"
What does it cost to have some junior level dev guy hack one and play around with it for a day and write up a report? Basically nothing.
"THey will build a patch that will work with a non hacked iPhone 100%. They won't spend a single dime testing it on a hacked one (why should they the ROI on that is a negative). "
OF course this is true, but you are answering a different question. Real testing and "validation" would be very expensive. Particularly since that validation would have to meet the standards of AT&T, which obviously has a vested interest in having any such thing fail validation testing.
"Simply say we can;t guarantee what it will do on a system with a changed state not done by Apple."
Unofficially, they will know perfectly well what it will do. If there are two roughly equal ways to implement a desired feature and and they know one of them breaks on the hacked phone -- that is the one that will be used. Apple would reverse engineer an unrelated reason for why they picked that implementation.
"From what some posters are posting on here (not the parent just what I have read) is that Apple should somehow make sure the patch will work with every combination of a hacked iPhone. Hmm wonder what that would cost."
They have no such obligation, totally agree. What they do have is a contract with AT&T to ensure and protect their exclusive carrier rights. If they don't do everything legally possible to make sure people can't switch carriers - they will sure Apple for everything they can.
-- your Web browser is Ronald Reagan
Except your statement assumes that Apple hacked a few iPods into the exact same state as all the hacked iPhones and already ran a patch to see what would happen.
That's a pretty damn safe assumption to make. Any COMPETENT product engineering team / product management team would ABSOLUTELY do so.
You KNOW that they have at LEAST applied the unlock hack to phones to see exactly what it does and how it works. You also know that they are working on (and surely finished by now) a patch that "undoes" the unlock hack.
It would be ridiculous to think that they would make the statement that their updates will brick a phone without knowing for sure.
It would also be ridiculous to think that any information on this at Apple would remain secret during a court case and the resulting subpoenas / depositions.
Come on. We, and Apple, just are not that stupid.
I read through some of the information on this Magnuson-Moss Warranty Act and it seems that the purpose here was to ensure that manufacturers provided the consumer with a document that is both easy to understand, and not ambiguous. However, it does not put any stipulation on that manufacturer to prevent them from invalidating the warranty if you don't use the device correctly.
However, this act falls a little short in the realm of electronics and firmware. Sure, Apple can't go around saying that your warranty will be void if you use a Motorolla bluetooth headset instead of an Apple one. But, can they say that the warranty is void if you use a different firmware? It seems to me that there's a gray area there. Firmware is required to make the device work, but it's provided by the manufacturer. So, can the manufacturer prevent you from using someone else's firmware by invalidating the warranty?
I suppose the underlying question is, what does the warranty cover? If it's merely electronics, then perhaps the manufacturer cannot dictate the firmware used, but, in the event of a failure, they can surely attempt to load the device with "official" firmware in an effort to determine the problem. Of course, if the unit is completely dead, that won't help. In that instance, the question becomes more of a "what caused the failure" type of question.
That's where 3rd party firmware can become a problem. How do you prove that the firmware was the cause and not the hardware? I'm sure it can be done, but to the satisfaction of the customer? And is it really Apple's responsibility to determine if the firmware was the cause? In the end, it may cost Apple quite a lot of money to make that determination, only to turn back to the customer and refuse the warranty claim. It's sort of a lose-lose situation.
XenoPhage
Technological Musings
You haven't spent much time working with real-time signal processing systems, have you?
By way of analogy, think about juggling: You don't throw the ball to where your hand is right now. You throw it to the correct spot in the pattern -- 12" off center, and 36" off the ground -- then make sure your hand is in the right place by the time the ball comes down. It requires some prediction and timing, but it's basically doable.
Now try doing it in an earthquake. The 'correct spot in the pattern' is no longer a simple location. You have to predict where the ground will be when the ball comes down, and adjust your throw accordingly. That's a lot more complicated, and there's always a chance that something will happen between the throw and the catch that you didn't predict.
The number of possible states and unpredictable events is more or less infinite, so there's no way you can possibly cover them all. The best you can do is try to keep everything within a range where you can spot the failures early enough to recover before they trigger a train wreck.
Systems like that are delicate. Screw with the timing just a little, and you can bump a few 'recoverable' cases over into the 'train wreck' category. They won't show up right away, though.. you have to get just the right combination of events before the thing will hang.
And with embedded systems, there's no option to shut down, reload the program, and start from a fresh, known state.
And, of course, the job is just that much harder when someone else has fiddled with the system in ways you don't know about.
Apple's announcement is just their way of saying they can't be positive they've hit every possible edge case that might cause this next update to interact badly with any unknown, unauthorized, and unsupported firmware tinkering people might have chosen to do on their own.
Honestly, I don't know why there's so much fuss about this. Hacking the firmware is very much an "at your own risk" procedure, and anyone who pretends not to know that is being deliberately stupid.
And why is everybody dumping this problem on Apple? Why aren't people yelling at the guys who released the unlocking software, demanding a "100% guaranteed or we'll replace your iPhone for free" reversion kit? If anyone should know how to return a hacked iPhone to its factory state, it would be the guys who hacked it in the first place.