High-volume data storage. There is a reason Google uses so many low-power machines instead of virtualizing everything.
And your counter-argument really doesn't make sense in context. You can't virtualize a supervisor, the VMs need a bare-metal machine to run on; that is what I was pointing out. In that context, your argument is that you can virtualize the hardware your VMs run on, which we both know is false; it can't be VMs all the way down. There has to be physical RAM, CPU, and storage somewhere.
Aaaaaaaaaaaand I missed the / in the closing em tag. Fail.
And another fail... I just read the first comment in the thread following this one and, well... Apple could comply with that, if that's actually what's being asked of them. In that case, kudos to Apple for not doing it.
It seems more that Apple cannot cooperate, which is what will keep the FBI from storming their facilities in the long run; their "unwillingness" to cooperate is simply cheap PR riding on the back of their inability to do so.
Don't get me wrong, their inability to cooperate is a good thing, it means they don't have a backdoor, nor do they mirror keys without user knowledge. Spinning it as them standing up to the FBI, rather than facts and science doing the same, is just hilarious, though.
I can write to NTFS in Ubuntu from any application running on the system, just like any other mounted disk. Ubuntu, however, does not ship with this ability out of the box; you have to enable 3rd-party sources in order to download the patent-encumbered libraries to enable it. I suggest reading me entire comment and not just the part you quoted; I never said it was impossible and, in fact, gave a popular example of how it is often worked around.
It is only 3rd party repair shops who don't have documentation telling them how to do this and once Error 53 is registered, it is irrecoverable. When Apple does the repair and pairs the new home button before any software updates are applied, all is good; if repair shops could do the pairing, the same would be true for them.
Android does this too, now. Has for a while now, though I'm not quite sure when it was introduced as I've used Lookout Mobile (as has my wife on her iPhone) for longer than either platform had the capability natively. Lookout's implementation is better than either platform's native implementation as well (more features), so I suggest checking it out.
And neither does the supervisor under which the VMs and containers run. It is clear that the poster of the "container and VM" comment is a very short-sighted thinker and didn't stop for long enough to realize that everything, even virtualized hardware, must run on real hardware and that real hardware requires drivers in one form or another. Hell, even virtualized hardware requires drivers, there are simply fewer of them.
People like this are the reason I won't work for someone else again; and I will never hire someone like this. My interview process includes questions intended to weed out people who believe that virtualized infrastructure is de-facto better than bare-metal solutions, because they fail to realize that a virtualized solution requires bare-metal to run in on the first place. The right tool for the job, people; sometimes that's a virtualization solution, sometimes it's not. Oh, and it always involves drivers, at some level.
The read-only support for NTFS is due to patent issues. It's the same reason NTFS-formatted hard disks sold for use with Macs include an NTFS driver; the Mac can read the disk just fine, but requires the driver to write to it due to patent issues for which Apple does not with to pay licensing (and rightly so).
Ah, yes, Android's fingerprint APIs & implementations are so wonderful that Google pay has been using them from day one, leading an ever growing number of developers to depend on them... Except that that is patently false
Then why did you just say it? It certainly isn't what I was claiming. Was that a lame attempt at a strawman, or did you simply misunderstand what I wrote? I suggest you go back and read my post again and figure it out.
Apple has imposed
Imposed? Upon whom? Themselves? Who else makes iOS-based phones? Nobody. If they did, there would be cheaper models without fingerprint scanners.
The fingerprint scanner, by the way, has nothing to do with Apple Pay; it is a novel way to unlock it, but that novelty wears off. With Android Pay, you unlock your phone (if you have a fingerprint scanner, you use that) and tap to the terminal; with Apple Pay, you unlock your phone, and tap to the terminal. Both allow you to tap first, only in the sense that the NFC antenna doesn't become active until you unlock, meaning that you must hold the device against the receiver while unlocking if you don't unlock first.
As for secure storage, which is what I was specifically talking about, Android has used that for Android Pay since day one; in fact, it is required for Android Pay. Google Wallet (the predecessor to Android Pay, predating Apple Pay by 3 and a half years), on the other hand, allows for the use of software-emulated secure storage (e.g. an encrypted filesystem image) on devices that lack a hardware solution, which are few and far between when looking at devices just slightly older than the iPhone 5s. Because Google Wallet is potentially less secure (in the case of devices lacking a hardware keystore), Google Wallet no longer supports NFC payments; that said, the number of devices that both support NFC and lack a hardware keystore is a statistical anomaly; if your Android phone supports NFC, you'll find yourself in the extreme minority if you can't use Google Pay.
But facts aren't as much fun because you can't really argue against them. Right?
You mean the hardware-based validation done by the Secure Enclave? Sorry, that occurs outside of the control of the OS; the CPU (you know, where the OS executes) doesn't play any role in that validation, it only looks at the result. Try again.
To further my point, the old behavior still exists, Error 53 still does not occur automatically; still only after a software update.
If you're going to argue with someone who has been following this issue since the iOS 9 internal beta, you might want to know WTF you're talking about before you open your mouth, or, at the very least, listen and learn when corrected. Don't let your rabid fanboyism blind you from facts; if iOS is still your preference, great, keep using it (I love my iPad and have yet to find an Android tablet I can actually use), but open your eyes to reality and learn the limitations of the OS and the devices that run it, so they don't bite my in the future. For the record, I handle Android with the same gloves.
I once again suggest you go look at the Nexus 5X and 6P, you're making yourself look deliberately ignorant now. Anddoid has supported (and high-end moddls have utilized) what Apple refers to as a Secure Enclave since Gingerbread, a little over 6 years now; it unified the APIs for hardware and software keystores with Ice Cream Sandwich, about 5 and a half years ago, so apps automatically make use of the haddware keystore if present. All of this was done before the Secure Enclave was even a glimmer in Apple's eye and, in fact, have had one i every Android phone I have owned for the past 4 years, starting with the HTC One X. Apple didn't release the iPhone 5s, the first phone with a Secure Enclave, untiil a year and a half later, and the One X wasn't even the first to use it; they've been in use since Gingerbread began supporting them, which was a reaction to Qualcomm, nVidia and Samsung starting to integrate them with their high-end SoCs. By now, every ARM manufacturer integrates them into at least their high-end chips; in fact, most (including Apple) base their decigns on ARM reference blocks.
Let's not let facts get in the way of our fanboyism, though; we might have a civil discussion if we allow that. I mean, it's not like I'm surrounddd by MacBook Pros and iPads [looks around] oh... wait. I am. At home, none the less; and I willingly married an iPhone user. I'm gonna go out on a limb and say that disqualifies me as a fanboy, while your deliberate ignorance of facts just screams it out loud.
I had a fingerprint scanner on my Atrix nearly 5 years ago; I'll admit it didn't work that well. What I'm saying is "when they start" came and went long before Apple even tried. I suggest you go look at a Nexus 6P or 5X, then talk; they use the same technology as the iPhone for their scanners, but they work a bit quicker and don't brick the device.
Show me an Android phone that bricks when you replace a part with a functional equivalent of the correct specifications. It means nothing that the iPhone's home button is replaceable if replacing it bricks the device weeks or months later. Don't be a dick.
Immediately cutting off the avenue of attack (disabling the power and data pins to the unauthenticated device) does the trick, actually. What doesn't protect the data on the device, however, is letting the unauthenticated hardware continue communicating with the functioning device for weeks or months until the next software update is applied. I might be inclined to agree with you if Error 53 happened as soon as the home button was replaced, but it doesn't, it gives potential attackers plenty of time to get at the user's data before locking the user out of it permanently. That's the wrong response.
I know this is Slashdot and nobody reads the articles, but you can't possibly have not been following this for weeks at this point. Do you seriously not understand what the actual issue is, here?
If I need to make a call in an emergency, I have my own phone. If at home, well, I needn't unlock my landline. Plus, as two other users have already pointed out, you don't unlock for emergency calls, you tap "Emergency Call" and dial emergency services.
The fact that you think there is no security risk in replacing hardware with unknown hardware indicates a *huge* lack of imagination on your part
And the fact that you think I think that indicates a *huge* lack of understanding on yours. My point was that the potential for attack is more than adequately mitigated by the measures Apple assured us (during the iPhone 5s launch) they implemented; only if Apple lied about implementing those measures, or implemented them with 1st-year CS student levels of incompetence, is there a possible attack vector here.
Imagine a malicious 'Touch ID' sensor that recorded the last fingerprint used.
This is precisely what the key exchange pairing prevents; if the scanner's private key has changed (e.g. because it was replaced), it can no longer communicate with the secure enclave in a way that the enclave can understand, rendering its ability to authenticate itself to the secure enclave null, which allows the secure enclave to deactivate it by way of disabling power and data pins for the device, which would prevent it from probing at the rest of the system. It can still function as a dumb button as it did for the iPhone 5 and older.
Again, either the security measures Apple bragged about during the iPhone 5s launch exist (in which case replacing the home button should immediately result in a non-functioning fingerprint reader, which does not happen) and they're lying about the possibility of an exploit, or they lied about those security measures.
Because there is no need. I wasn't complaining about having to type in a PIN I was pointing out that the fingerprint is unnecessary; adding my finger to her phone would be solving a problem that doesn't exist, worthless effort.
I'm fairly certain they don't open up a Mac for anything beyond replacing/upgrading RAM and storage; and that's on the models where such is even possible. I also find it interesting that, if they are capable of replacing screens on-site, they rather insist on replacing the entire device; for a fee, of course. Perhaps it's just select locations, but I can tell you for certain that the Apple stores in my area (East Bay, just an hour north of Cupertino) do not do repairs.
Indeed, the claim is that the fingerprint hash is stored in the secure enclave and can not be read from it. It's actually pretty damn smart, honestly; enclave gets placed into storage mode and is fed a fingerprint hash, which it stores; then, enclave receives a hash in comparison mode and only has to answer "yes" or "no" as to whether it's a match. As for Apple Pay, the secure enclave stores a token generated by the card issuer and uses that token to generate authorization responses for given transactions. In that way, data that is written to the secure enclave never need be read from it, so it's perfectly reasonable to not be able to read from it; erasing is simply a matter of overwriting with zeroes.
That said, for the security vulnerability that Apple wants us to think they're protecting us from to actually exist, the secure enclave itself must be flawed or Apple must be lying about how it works. In either case, Apple is lying about something.
Sideloading is both perfectly safe and extremely dangerous at the same time. App I developed myself? Perfectly safe to sideload. Random app off the internet? Dangerous without implicit and properly-placed trust in the developer. App developed by my employer? Well, that depends on the employer and why they want me to install the app, but I'm probably safe there.
It's downmodded because of who posted it. In this instance, I have to say it should be modded up because it's actually useful information (well, 2/3 of it) but, after a tiff with the poster which resulted in me losing a fair bit of karma, I don't have available mod points to correct it; had I not been stabbed in the back, this would not be the case.
Instead, I'll just post (and without the karma modifier that will get my post in front of more eyeballs) to suggest that those with mod points make the correction for the better of the community.
Slashdot Mirror
Yup, said this in my followup comment, where I also requested that my post be harmlessly modded out of view.
High-volume data storage. There is a reason Google uses so many low-power machines instead of virtualizing everything.
And your counter-argument really doesn't make sense in context. You can't virtualize a supervisor, the VMs need a bare-metal machine to run on; that is what I was pointing out. In that context, your argument is that you can virtualize the hardware your VMs run on, which we both know is false; it can't be VMs all the way down. There has to be physical RAM, CPU, and storage somewhere.
Aaaaaaaaaaaand I missed the / in the closing em tag. Fail.
And another fail... I just read the first comment in the thread following this one and, well... Apple could comply with that, if that's actually what's being asked of them. In that case, kudos to Apple for not doing it.
Mods? how about some overrateds here?
It seems more that Apple cannot cooperate, which is what will keep the FBI from storming their facilities in the long run; their "unwillingness" to cooperate is simply cheap PR riding on the back of their inability to do so.
Don't get me wrong, their inability to cooperate is a good thing, it means they don't have a backdoor, nor do they mirror keys without user knowledge. Spinning it as them standing up to the FBI, rather than facts and science doing the same, is just hilarious, though.
I can write to NTFS in Ubuntu from any application running on the system, just like any other mounted disk. Ubuntu, however, does not ship with this ability out of the box; you have to enable 3rd-party sources in order to download the patent-encumbered libraries to enable it. I suggest reading me entire comment and not just the part you quoted; I never said it was impossible and, in fact, gave a popular example of how it is often worked around.
Well, Apple can re-pair after replacement, so...
It is only 3rd party repair shops who don't have documentation telling them how to do this and once Error 53 is registered, it is irrecoverable. When Apple does the repair and pairs the new home button before any software updates are applied, all is good; if repair shops could do the pairing, the same would be true for them.
Android does this too, now. Has for a while now, though I'm not quite sure when it was introduced as I've used Lookout Mobile (as has my wife on her iPhone) for longer than either platform had the capability natively. Lookout's implementation is better than either platform's native implementation as well (more features), so I suggest checking it out.
And neither does the supervisor under which the VMs and containers run. It is clear that the poster of the "container and VM" comment is a very short-sighted thinker and didn't stop for long enough to realize that everything, even virtualized hardware, must run on real hardware and that real hardware requires drivers in one form or another. Hell, even virtualized hardware requires drivers, there are simply fewer of them.
People like this are the reason I won't work for someone else again; and I will never hire someone like this. My interview process includes questions intended to weed out people who believe that virtualized infrastructure is de-facto better than bare-metal solutions, because they fail to realize that a virtualized solution requires bare-metal to run in on the first place. The right tool for the job, people; sometimes that's a virtualization solution, sometimes it's not. Oh, and it always involves drivers, at some level.
The read-only support for NTFS is due to patent issues. It's the same reason NTFS-formatted hard disks sold for use with Macs include an NTFS driver; the Mac can read the disk just fine, but requires the driver to write to it due to patent issues for which Apple does not with to pay licensing (and rightly so).
Ah, yes, Android's fingerprint APIs & implementations are so wonderful that Google pay has been using them from day one, leading an ever growing number of developers to depend on them... Except that that is patently false
Then why did you just say it? It certainly isn't what I was claiming. Was that a lame attempt at a strawman, or did you simply misunderstand what I wrote? I suggest you go back and read my post again and figure it out.
Apple has imposed
Imposed? Upon whom? Themselves? Who else makes iOS-based phones? Nobody. If they did, there would be cheaper models without fingerprint scanners.
The fingerprint scanner, by the way, has nothing to do with Apple Pay; it is a novel way to unlock it, but that novelty wears off. With Android Pay, you unlock your phone (if you have a fingerprint scanner, you use that) and tap to the terminal; with Apple Pay, you unlock your phone, and tap to the terminal. Both allow you to tap first, only in the sense that the NFC antenna doesn't become active until you unlock, meaning that you must hold the device against the receiver while unlocking if you don't unlock first.
As for secure storage, which is what I was specifically talking about, Android has used that for Android Pay since day one; in fact, it is required for Android Pay. Google Wallet (the predecessor to Android Pay, predating Apple Pay by 3 and a half years), on the other hand, allows for the use of software-emulated secure storage (e.g. an encrypted filesystem image) on devices that lack a hardware solution, which are few and far between when looking at devices just slightly older than the iPhone 5s. Because Google Wallet is potentially less secure (in the case of devices lacking a hardware keystore), Google Wallet no longer supports NFC payments; that said, the number of devices that both support NFC and lack a hardware keystore is a statistical anomaly; if your Android phone supports NFC, you'll find yourself in the extreme minority if you can't use Google Pay.
But facts aren't as much fun because you can't really argue against them. Right?
You mean the hardware-based validation done by the Secure Enclave? Sorry, that occurs outside of the control of the OS; the CPU (you know, where the OS executes) doesn't play any role in that validation, it only looks at the result. Try again.
To further my point, the old behavior still exists, Error 53 still does not occur automatically; still only after a software update.
If you're going to argue with someone who has been following this issue since the iOS 9 internal beta, you might want to know WTF you're talking about before you open your mouth, or, at the very least, listen and learn when corrected. Don't let your rabid fanboyism blind you from facts; if iOS is still your preference, great, keep using it (I love my iPad and have yet to find an Android tablet I can actually use), but open your eyes to reality and learn the limitations of the OS and the devices that run it, so they don't bite my in the future. For the record, I handle Android with the same gloves.
Typos... This is why I don't usually post from my phone.
I once again suggest you go look at the Nexus 5X and 6P, you're making yourself look deliberately ignorant now. Anddoid has supported (and high-end moddls have utilized) what Apple refers to as a Secure Enclave since Gingerbread, a little over 6 years now; it unified the APIs for hardware and software keystores with Ice Cream Sandwich, about 5 and a half years ago, so apps automatically make use of the haddware keystore if present. All of this was done before the Secure Enclave was even a glimmer in Apple's eye and, in fact, have had one i every Android phone I have owned for the past 4 years, starting with the HTC One X. Apple didn't release the iPhone 5s, the first phone with a Secure Enclave, untiil a year and a half later, and the One X wasn't even the first to use it; they've been in use since Gingerbread began supporting them, which was a reaction to Qualcomm, nVidia and Samsung starting to integrate them with their high-end SoCs. By now, every ARM manufacturer integrates them into at least their high-end chips; in fact, most (including Apple) base their decigns on ARM reference blocks.
Let's not let facts get in the way of our fanboyism, though; we might have a civil discussion if we allow that. I mean, it's not like I'm surrounddd by MacBook Pros and iPads [looks around] oh... wait. I am. At home, none the less; and I willingly married an iPhone user. I'm gonna go out on a limb and say that disqualifies me as a fanboy, while your deliberate ignorance of facts just screams it out loud.
I had a fingerprint scanner on my Atrix nearly 5 years ago; I'll admit it didn't work that well. What I'm saying is "when they start" came and went long before Apple even tried. I suggest you go look at a Nexus 6P or 5X, then talk; they use the same technology as the iPhone for their scanners, but they work a bit quicker and don't brick the device.
Show me an Android phone that bricks when you replace a part with a functional equivalent of the correct specifications. It means nothing that the iPhone's home button is replaceable if replacing it bricks the device weeks or months later. Don't be a dick.
Immediately cutting off the avenue of attack (disabling the power and data pins to the unauthenticated device) does the trick, actually. What doesn't protect the data on the device, however, is letting the unauthenticated hardware continue communicating with the functioning device for weeks or months until the next software update is applied. I might be inclined to agree with you if Error 53 happened as soon as the home button was replaced, but it doesn't, it gives potential attackers plenty of time to get at the user's data before locking the user out of it permanently. That's the wrong response.
I know this is Slashdot and nobody reads the articles, but you can't possibly have not been following this for weeks at this point. Do you seriously not understand what the actual issue is, here?
If I need to make a call in an emergency, I have my own phone. If at home, well, I needn't unlock my landline. Plus, as two other users have already pointed out, you don't unlock for emergency calls, you tap "Emergency Call" and dial emergency services.
The fact that you think there is no security risk in replacing hardware with unknown hardware indicates a *huge* lack of imagination on your part
And the fact that you think I think that indicates a *huge* lack of understanding on yours. My point was that the potential for attack is more than adequately mitigated by the measures Apple assured us (during the iPhone 5s launch) they implemented; only if Apple lied about implementing those measures, or implemented them with 1st-year CS student levels of incompetence, is there a possible attack vector here.
Imagine a malicious 'Touch ID' sensor that recorded the last fingerprint used.
This is precisely what the key exchange pairing prevents; if the scanner's private key has changed (e.g. because it was replaced), it can no longer communicate with the secure enclave in a way that the enclave can understand, rendering its ability to authenticate itself to the secure enclave null, which allows the secure enclave to deactivate it by way of disabling power and data pins for the device, which would prevent it from probing at the rest of the system. It can still function as a dumb button as it did for the iPhone 5 and older.
Again, either the security measures Apple bragged about during the iPhone 5s launch exist (in which case replacing the home button should immediately result in a non-functioning fingerprint reader, which does not happen) and they're lying about the possibility of an exploit, or they lied about those security measures.
Because there is no need. I wasn't complaining about having to type in a PIN I was pointing out that the fingerprint is unnecessary; adding my finger to her phone would be solving a problem that doesn't exist, worthless effort.
I'm fairly certain they don't open up a Mac for anything beyond replacing/upgrading RAM and storage; and that's on the models where such is even possible. I also find it interesting that, if they are capable of replacing screens on-site, they rather insist on replacing the entire device; for a fee, of course. Perhaps it's just select locations, but I can tell you for certain that the Apple stores in my area (East Bay, just an hour north of Cupertino) do not do repairs.
Indeed, the claim is that the fingerprint hash is stored in the secure enclave and can not be read from it. It's actually pretty damn smart, honestly; enclave gets placed into storage mode and is fed a fingerprint hash, which it stores; then, enclave receives a hash in comparison mode and only has to answer "yes" or "no" as to whether it's a match. As for Apple Pay, the secure enclave stores a token generated by the card issuer and uses that token to generate authorization responses for given transactions. In that way, data that is written to the secure enclave never need be read from it, so it's perfectly reasonable to not be able to read from it; erasing is simply a matter of overwriting with zeroes.
That said, for the security vulnerability that Apple wants us to think they're protecting us from to actually exist, the secure enclave itself must be flawed or Apple must be lying about how it works. In either case, Apple is lying about something.
Bricking is irreparable, like Error 53.
Sideloading is both perfectly safe and extremely dangerous at the same time. App I developed myself? Perfectly safe to sideload. Random app off the internet? Dangerous without implicit and properly-placed trust in the developer. App developed by my employer? Well, that depends on the employer and why they want me to install the app, but I'm probably safe there.
It's downmodded because of who posted it. In this instance, I have to say it should be modded up because it's actually useful information (well, 2/3 of it) but, after a tiff with the poster which resulted in me losing a fair bit of karma, I don't have available mod points to correct it; had I not been stabbed in the back, this would not be the case.
Instead, I'll just post (and without the karma modifier that will get my post in front of more eyeballs) to suggest that those with mod points make the correction for the better of the community.
permitting unauthorized access to the crypto store
The crypto store that, according to Apple is write-only?