The problem is, it wasn't his phone and the owner is also locked out of it. If that is the case, and the owner wants to help (which it would seem they do), then it should be the city of Sane Bernadino seeking this and, while they still wouldn't comply, nobody would think twice about it if they did. The city of San Bernadino could then hand over any relevant information to the FBI. The headlines on both stories would read "Malicious User Changes iPhone Credentials, Apple Helps Regain Access" and "Terrorized City Recovers Information, Aids FBI Investigation".
For example, if the FBI Apple a court order to install a compromised firmware on behalf of the city of San Bernadino, when the city brought them the phone, and presented the city with both the phone and a warrant for its contents and a court order to comply, city officials would be asking Apple to compromise their own phone, which should be acceptable. A court order forcing a vendor to comply with a customer request relating to their own property should also be acceptable. The only questionable part then becomes the warrant and court order served to the city itself, for which there is plenty of precedent; we've already shown that we accept entities being made to share their own records, or face their own consequences if they do no. The problem is that the city, ostensibly innocent in this, is being removed from the loop regarding the handling of their own property.
Also to note: if we don't fight that fight here, we allow a precedent to be set that allows the government to do the same in any case.
You might have missed when this issue first hit the news, months ago, but it did. And, at that time, Error 53 only popped up during a software update. It certainly wasn't a security feature then, when it allowed a would-be attacker to replace the sensor and have it keep working (which also should not have been possible given how Apple claims the sensor works with the Secure Enclave) for weeks or months. And, most likely, that was a bug in the first place.
I was wondering why it was suddenly getting so much attention in the news when is barely got a mention last year; another poster went as far as buying a brand new iPhone to test with and found that it now does trigger the error immediately. Now, that is newsworthy and, most likely, also a bug as Apple has issued an update to fix it and only disable the sensor (e.g. what the story we're discussing here is about in the first place), which is all that is necessary if the sensor is potentially compromised.
Wow, you really went all out, there, thank you for confirming. I do know that, prior to 9.2, it only happened during software updates (and yes, this was an issue prior to 9.2), so I had no reason to beleive that had changed. This was first covered on Slashdot a few months ago, likely weeks after it was covered everywhere else (hey, it's Slashdot after all) and I was really wondering why it was getting so nuch attention recently when the story mostly flew under the radar last year. You have answered that question and corrected my undersyanding of the issue.
That said, Apple's next update is supposed to fix this by only disabling the fingerprint sensor and not the entire device. Clearly, Apple agrees it was overkill; likely even unintentional, as this is merely a more eager presentation of a previously known issue.
And, for the record, I wasn't baiting. None the less, thank you for taking the time (and risk) to test that. Also, please excuse any typos, I'm posting from my phone.
If that is, in fact, what the update is, then I applaud Apple for doing it. There really and truly is no reason to disable any more than the sensor in this case.
You would potentially have thought correctly if not for the fact that Error 53 crops up weeks or months after the repair, when software updates are applied. If it were immediate, it might be a security feature; but, then, that the sensor and phone are paired and a replacement sensor shouldn't be able to work at all without Apple's blessing should be enough to prevent such an attack.
Now what will happen is you'll use a insecure sensor, apple will still allow the phone to boot, and a bunch of dumbasses will go ahead and use the phone with a compromised sensor
You mean, what happens now? You do realize that Error 53 doesn't happen immediately (it would possibly be a security feature if it did) but, instead, happens weeks or months later when software updates are applied. A proper security feature would be deactivating power and data pins for the sensor if it fails to authenticate itself at boot, permanently disabling it after a set number of failures. No need to disable the entire phone; the non-working sensor should alert the user to the problem.
The trade in credit for your existing phone is universally laughably bad
Unless you subscribe to T-Mobile's JUMP! plan, wherein they pay the remainder of what you owe on the device as a trade-in. The only downside I've seen is that it basically punishes you for not upgrading as soon as you're eligible, but even at that the trade-in value is more than other programs are offering. By the time the phone is paid in full, its trade-in value would be near zero anyway, but then you own it and can sell it if you so choose.
In fact, Apple's new program is almost identical to JUMP! except that JUMP! includes phone insurance and a handful of other services not included in Apple's offering. Ignoring that (and many here will, especially if they would not use those services in the first place, which is fair), they offer the same utility and the same drawbacks, the primary benefit to JUMP! being that you can choose any phone T-Mobile sells.
For me, the primary benefit of JUMP! was that, at $10/mo per phone, it cost $3.98/mo less than insurance for two phones, and it included the insurance! The guaranteed trade-in value, Lookout Mobile Premium ($9.98/mo for two phones) subscription, and Rhapsody ($9.98/mo for two users) subscriptions are just bonuses at that point; and, since I do use those services, that's a savings of $23.94/mo for me. Of course, JUMP! just went up to $12/mo for the phones I have, but I'm fine with that given that the insurance went up to $14.99/mo, increasing my savings on that to $5.98/mo and my overall savings to $25.94/mo.
If I were to leave T-Mobile for an MVNO, assuming I were willing to give up my unlimited data to do so, having to pay for continued use of Lookout and Rhapsody or both phones would put me right about where I am now, bill-wise. I might save a dollar or two per month, but the loss of insurance and trade-in value makes that not worthwhile.
This. Though I do have to say iOS seems to beat Android in the tablet realm; possibly just down to how I use a tablet vs how I use my phone. That said, I just got a Yoga Tablet 2 running Win 8.1 (immediately upgraded to Win 10) and the ability to switch between tablet mode and desktop mode while running full desktop applications is a godsend; the 15hr battery life ain't half bad either. Beats the pants off of anything I've seen from iOS or Android.
Please allow me to apologize for the tone with which I opened the above response; I had not yet finished reading your entire post when I started my reply, which was irresponsible of me (but also apparently common practice here in Slashdot). I now see that you're actually interested in learning and not simply trying to be dense. Please understand that the latter is much more common than the former here.
I gave the salient example a couple posts up but, since it seems to be a theme here, I'll repeat myself: High-volume data storage.
It's not trivial to simply throw more hardware at an RBDMS, you have to handle primary key collisions and no, UUID is not a solution as not only are collisions still possible, using massively non-sequential data as a primary key is absolute murder on database performance, meaning you must throw even more hardware at the problem to compensate. And, even if that were sufficient, the redundancy, isolation, and fault tolerance "benefits" (all of which you can gain with properly configured bare metal systems, as well) go out the window on a write-heavy system, due to something commonly known as propagation delay. Isolation simply means a separate running environment for each application (or part thereof, depending on how fine-grained you want to get), which can be had with physical hardware as well; it often doesn't make sense if you're running low-load, low-traffic stuff, which is where virtualization steps in, but it's not per se a benefit of virtualization, just a good general engineering principle. Fault tolerance is introduced through various means; running multiple instances of the same service with the same data (e.g. hot spares) and maintaining up-to-the-moment current backups (e.g. realtime data replication) are the two most common, both heavily overlapping the other mentioned benefit, redundancy, and both possible with physical hardware; therefore, not benefits of virtualization. If you're generating data faster than you can replicate it to your hot spares or backups and the system goes down, you're boned regardless.
The real benefits of virtualization include the ability to run several lower-traffic virtual hosts on a single physical machine rather than several separate machines which are likely overpowered for their respective tasks (in the case of virtualizing on your own physical hardware), and the ability to quickly scale an application to massive size (in the case of virtualizing on someone else's hardware). The former certainly represents significant cost savings, which is a benefit in and of itself, while the latter represents extreme flexibility. The reason scalability isn't a benefit of virtualizing on your own hardware should be clear, but I'll state it anyway; you aren't saving anything if you have to have the hardware on-site, configured, and standing by anyway.
I'm not knocking virtualization and container solutions at all, here; they have their uses and I utilize them extensively. The only systems I don't virtualize are my personal systems and my NAS, because it makes zero sense to do so; I also don't run any write-heavy or high traffic data storage (other than the NAS), so even my databases are virtualized at this point. That may not always be the case, though.
A tautology, it was, right down to my (slightly embarrassing) use of "supervisor" instead of "hypervisor", a mistake I made in that post, as well as the one before it.
So, why make such an obvious statement? A few posts up, you'll see why the statement was originally made: someone claimed that drivers are becoming less important because everything is VMs and containers now, to which someone replied that end users don't use VMs. I replied to that, in agreement, and expanded on the point, a the original poster was clearly missing that bit of the picture.
Why repeat it? Because my assertion that there must be bare metal somewhere is not only not intrinsically wrong, it's note wrong at all; someone who would say it's "not wrong per se" clearly missed that point and needed it explained again, in slightly different terms. Three different ways in this case, so I know I won't have to come back and explain it yet again. You seem to have gotten it this time, so I'd say it worked.
Uh... First of all, it's not a matter of embarassment, it's a matter of not wanting to spread misinformation; however, your logic seems sound and I agree with it. Second, I never mentioned APK in this thread; in fact, the only mention of APK in this thread before your post right here came from an AC a full 6 and a half hours after you told me to "drop it". Your twisted representation of events once again makes me question the logic you just had me agreeing with, as well as your affiliations, since you sure seem to think I was talking about APK when I had made no mention of him; he's dead to me after our tiff last weak, why would I bring him up? That was you, friend, and it makes clear your motives.
and no one is interesting in reading about it any longer
I would be inclined to agree, so why'd you bring it up? I'd also be inclined to think that people, perhaps, are interested in my posts, given that all of your moderation has been undone, except for the post where I specifically asked to be downmodded.
Uh... It was my own post that I was asking be downmodded, as I was mistaken on my facts when I posted it. If I was trying to censor someone else's post and I, as you said, always have a spare mod point, would not I have modded it myself? Think, buddy, before you open you anonymous piehole.
I'm also wondering if the AC who also replied here is right. It might be time to retain legal council.
Oh, don't you know it! Asking that my mistaken post be modded down, to hide the incorrect information it contains from the general audience; only a total wanker would want to prevent the spreading of misinformation.
Sorry to break it to you, but the post you were replying to was in error and it seems they actually can comply with what's actually being asked of them. You and I made the same incorrect assumption, friend.
That said, while their inability to comply with what we both assumed they were being asked to do is intentional, Apple's intent was simply to not have to worry about being bothered with requests to decrypt phones; they accomplish this simply by rendering it technicall impossibly for them to do so. That's a purely selfish motive, but one that does benefit us; the PR that comes with it is cheap, even if it is a legitimate benefit to users.
It seems as though you're defending Apple from an attack I was not making; hopefully this clears the air.
LOL I do it all the time... I almost never reload to check for new comments, even when I opened the page hours ago; the only exception is when little or no conversation has occurred by the time I open the page. No worries and thanks for being one of the few here not to jump on someone for admitting they were wrong (and then pointing it out yet again).
If you read through my post history, you'll learn that I do, in fact, know what the Secure Enclave is. Further, if you read my follow-up post, you'll note that I am already aware of my mistake here. Perhaps I shouldn't feel bad about not reading entire threads before commenting; apparently nobody else does either.
Actually, as there were only 5 posts in the thread when I loaded the page, I have to say the post I am referring to was the first, at least in this conversation.
Interesting info; the FUSE driver that came with my wife's Toshiba external driver included documentation to the contrary. Still learning things here, that's why I keep coming back.
Slashdot Mirror
I accidentally a whole word. "For example, if the FBI Apple a court order" should be "For example, if the FBI served Apple a court order".
The problem is, it wasn't his phone and the owner is also locked out of it. If that is the case, and the owner wants to help (which it would seem they do), then it should be the city of Sane Bernadino seeking this and, while they still wouldn't comply, nobody would think twice about it if they did. The city of San Bernadino could then hand over any relevant information to the FBI. The headlines on both stories would read "Malicious User Changes iPhone Credentials, Apple Helps Regain Access" and "Terrorized City Recovers Information, Aids FBI Investigation".
For example, if the FBI Apple a court order to install a compromised firmware on behalf of the city of San Bernadino, when the city brought them the phone, and presented the city with both the phone and a warrant for its contents and a court order to comply, city officials would be asking Apple to compromise their own phone, which should be acceptable. A court order forcing a vendor to comply with a customer request relating to their own property should also be acceptable. The only questionable part then becomes the warrant and court order served to the city itself, for which there is plenty of precedent; we've already shown that we accept entities being made to share their own records, or face their own consequences if they do no. The problem is that the city, ostensibly innocent in this, is being removed from the loop regarding the handling of their own property.
Also to note: if we don't fight that fight here, we allow a precedent to be set that allows the government to do the same in any case.
You might have missed when this issue first hit the news, months ago, but it did. And, at that time, Error 53 only popped up during a software update. It certainly wasn't a security feature then, when it allowed a would-be attacker to replace the sensor and have it keep working (which also should not have been possible given how Apple claims the sensor works with the Secure Enclave) for weeks or months. And, most likely, that was a bug in the first place.
I was wondering why it was suddenly getting so much attention in the news when is barely got a mention last year; another poster went as far as buying a brand new iPhone to test with and found that it now does trigger the error immediately. Now, that is newsworthy and, most likely, also a bug as Apple has issued an update to fix it and only disable the sensor (e.g. what the story we're discussing here is about in the first place), which is all that is necessary if the sensor is potentially compromised.
Wow, you really went all out, there, thank you for confirming. I do know that, prior to 9.2, it only happened during software updates (and yes, this was an issue prior to 9.2), so I had no reason to beleive that had changed. This was first covered on Slashdot a few months ago, likely weeks after it was covered everywhere else (hey, it's Slashdot after all) and I was really wondering why it was getting so nuch attention recently when the story mostly flew under the radar last year. You have answered that question and corrected my undersyanding of the issue.
That said, Apple's next update is supposed to fix this by only disabling the fingerprint sensor and not the entire device. Clearly, Apple agrees it was overkill; likely even unintentional, as this is merely a more eager presentation of a previously known issue.
And, for the record, I wasn't baiting. None the less, thank you for taking the time (and risk) to test that. Also, please excuse any typos, I'm posting from my phone.
If that is, in fact, what the update is, then I applaud Apple for doing it. There really and truly is no reason to disable any more than the sensor in this case.
You would potentially have thought correctly if not for the fact that Error 53 crops up weeks or months after the repair, when software updates are applied. If it were immediate, it might be a security feature; but, then, that the sensor and phone are paired and a replacement sensor shouldn't be able to work at all without Apple's blessing should be enough to prevent such an attack.
Now what will happen is you'll use a insecure sensor, apple will still allow the phone to boot, and a bunch of dumbasses will go ahead and use the phone with a compromised sensor
You mean, what happens now? You do realize that Error 53 doesn't happen immediately (it would possibly be a security feature if it did) but, instead, happens weeks or months later when software updates are applied. A proper security feature would be deactivating power and data pins for the sensor if it fails to authenticate itself at boot, permanently disabling it after a set number of failures. No need to disable the entire phone; the non-working sensor should alert the user to the problem.
The trade in credit for your existing phone is universally laughably bad
Unless you subscribe to T-Mobile's JUMP! plan, wherein they pay the remainder of what you owe on the device as a trade-in. The only downside I've seen is that it basically punishes you for not upgrading as soon as you're eligible, but even at that the trade-in value is more than other programs are offering. By the time the phone is paid in full, its trade-in value would be near zero anyway, but then you own it and can sell it if you so choose.
In fact, Apple's new program is almost identical to JUMP! except that JUMP! includes phone insurance and a handful of other services not included in Apple's offering. Ignoring that (and many here will, especially if they would not use those services in the first place, which is fair), they offer the same utility and the same drawbacks, the primary benefit to JUMP! being that you can choose any phone T-Mobile sells.
For me, the primary benefit of JUMP! was that, at $10/mo per phone, it cost $3.98/mo less than insurance for two phones, and it included the insurance! The guaranteed trade-in value, Lookout Mobile Premium ($9.98/mo for two phones) subscription, and Rhapsody ($9.98/mo for two users) subscriptions are just bonuses at that point; and, since I do use those services, that's a savings of $23.94/mo for me. Of course, JUMP! just went up to $12/mo for the phones I have, but I'm fine with that given that the insurance went up to $14.99/mo, increasing my savings on that to $5.98/mo and my overall savings to $25.94/mo.
If I were to leave T-Mobile for an MVNO, assuming I were willing to give up my unlimited data to do so, having to pay for continued use of Lookout and Rhapsody or both phones would put me right about where I am now, bill-wise. I might save a dollar or two per month, but the loss of insurance and trade-in value makes that not worthwhile.
This. Though I do have to say iOS seems to beat Android in the tablet realm; possibly just down to how I use a tablet vs how I use my phone. That said, I just got a Yoga Tablet 2 running Win 8.1 (immediately upgraded to Win 10) and the ability to switch between tablet mode and desktop mode while running full desktop applications is a godsend; the 15hr battery life ain't half bad either. Beats the pants off of anything I've seen from iOS or Android.
I financed my Nexus 6 just fine; does your carrier not offer 0% financing and a fair-value trade-in program?
Please allow me to apologize for the tone with which I opened the above response; I had not yet finished reading your entire post when I started my reply, which was irresponsible of me (but also apparently common practice here in Slashdot). I now see that you're actually interested in learning and not simply trying to be dense. Please understand that the latter is much more common than the former here.
I gave the salient example a couple posts up but, since it seems to be a theme here, I'll repeat myself: High-volume data storage.
It's not trivial to simply throw more hardware at an RBDMS, you have to handle primary key collisions and no, UUID is not a solution as not only are collisions still possible, using massively non-sequential data as a primary key is absolute murder on database performance, meaning you must throw even more hardware at the problem to compensate. And, even if that were sufficient, the redundancy, isolation, and fault tolerance "benefits" (all of which you can gain with properly configured bare metal systems, as well) go out the window on a write-heavy system, due to something commonly known as propagation delay. Isolation simply means a separate running environment for each application (or part thereof, depending on how fine-grained you want to get), which can be had with physical hardware as well; it often doesn't make sense if you're running low-load, low-traffic stuff, which is where virtualization steps in, but it's not per se a benefit of virtualization, just a good general engineering principle. Fault tolerance is introduced through various means; running multiple instances of the same service with the same data (e.g. hot spares) and maintaining up-to-the-moment current backups (e.g. realtime data replication) are the two most common, both heavily overlapping the other mentioned benefit, redundancy, and both possible with physical hardware; therefore, not benefits of virtualization. If you're generating data faster than you can replicate it to your hot spares or backups and the system goes down, you're boned regardless.
The real benefits of virtualization include the ability to run several lower-traffic virtual hosts on a single physical machine rather than several separate machines which are likely overpowered for their respective tasks (in the case of virtualizing on your own physical hardware), and the ability to quickly scale an application to massive size (in the case of virtualizing on someone else's hardware). The former certainly represents significant cost savings, which is a benefit in and of itself, while the latter represents extreme flexibility. The reason scalability isn't a benefit of virtualizing on your own hardware should be clear, but I'll state it anyway; you aren't saving anything if you have to have the hardware on-site, configured, and standing by anyway.
I'm not knocking virtualization and container solutions at all, here; they have their uses and I utilize them extensively. The only systems I don't virtualize are my personal systems and my NAS, because it makes zero sense to do so; I also don't run any write-heavy or high traffic data storage (other than the NAS), so even my databases are virtualized at this point. That may not always be the case, though.
A tautology, it was, right down to my (slightly embarrassing) use of "supervisor" instead of "hypervisor", a mistake I made in that post, as well as the one before it.
So, why make such an obvious statement? A few posts up, you'll see why the statement was originally made: someone claimed that drivers are becoming less important because everything is VMs and containers now, to which someone replied that end users don't use VMs. I replied to that, in agreement, and expanded on the point, a the original poster was clearly missing that bit of the picture.
Why repeat it? Because my assertion that there must be bare metal somewhere is not only not intrinsically wrong, it's note wrong at all; someone who would say it's "not wrong per se" clearly missed that point and needed it explained again, in slightly different terms. Three different ways in this case, so I know I won't have to come back and explain it yet again. You seem to have gotten it this time, so I'd say it worked.
and no one is interesting in reading about it any longer
I would be inclined to agree, so why'd you bring it up? I'd also be inclined to think that people, perhaps, are interested in my posts, given that all of your moderation has been undone, except for the post where I specifically asked to be downmodded.
Uh... It was my own post that I was asking be downmodded, as I was mistaken on my facts when I posted it. If I was trying to censor someone else's post and I, as you said, always have a spare mod point, would not I have modded it myself? Think, buddy, before you open you anonymous piehole.
I'm also wondering if the AC who also replied here is right. It might be time to retain legal council.
Oh, don't you know it! Asking that my mistaken post be modded down, to hide the incorrect information it contains from the general audience; only a total wanker would want to prevent the spreading of misinformation.
I have to admit, though... The FBI saw this one coming and had a plan for it.
Eh... Hi there, Anonymous Coward. Thank you for your thoughtful and productive comment, it has really added to the conversation.
Really, mods? I was asking that the PARENT post be modded down. Let's get a few overrateds up there, eh? ;)
Sorry to break it to you, but the post you were replying to was in error and it seems they actually can comply with what's actually being asked of them. You and I made the same incorrect assumption, friend.
That said, while their inability to comply with what we both assumed they were being asked to do is intentional, Apple's intent was simply to not have to worry about being bothered with requests to decrypt phones; they accomplish this simply by rendering it technicall impossibly for them to do so. That's a purely selfish motive, but one that does benefit us; the PR that comes with it is cheap, even if it is a legitimate benefit to users.
It seems as though you're defending Apple from an attack I was not making; hopefully this clears the air.
In one or another
It seems this article has lost its "way".
LOL I do it all the time... I almost never reload to check for new comments, even when I opened the page hours ago; the only exception is when little or no conversation has occurred by the time I open the page. No worries and thanks for being one of the few here not to jump on someone for admitting they were wrong (and then pointing it out yet again).
If you read through my post history, you'll learn that I do, in fact, know what the Secure Enclave is. Further, if you read my follow-up post, you'll note that I am already aware of my mistake here. Perhaps I shouldn't feel bad about not reading entire threads before commenting; apparently nobody else does either.
Actually, as there were only 5 posts in the thread when I loaded the page, I have to say the post I am referring to was the first, at least in this conversation.
Interesting info; the FUSE driver that came with my wife's Toshiba external driver included documentation to the contrary. Still learning things here, that's why I keep coming back.