Here’s the problem I have with this whole story. If the reason Apple provided explained the situation 100%, then we should have been hearing reports of older iPhones suddenly crashing at ~30% battery charge for years. But we didn’t... the issue only started rearing it’s head after iOS 10.x came around.
So why didn’t older iPhones have this problem with iOS 9, or 8, or earlier?
Because, as the CPU/GPU speed/number of cores, etc. went up in models that happened to be released at the same time as those versions of iOS, the ability for those systems to MOMENTARILY draw enough power to cause a dip in battery-voltage deliverable to the system (and thus a power-management panic) increased to the point where it wasn't as rare of an occurence as it once was.
The issue isn't about how long the battery lasts. It's about how much power the battery can supply at a given moment. There's a huge variance in how much power the phone needs depending on what you're doing at the moment. Accessing flash memory, enabling GPS/camera/bluetooth, downloading data, stressing the CPU, are all things that will make the power draw go up. You need to make sure the battery can handle the power spikes. If the battery can't handle the load, the phone just shuts off with no warning.
The update slows the phone down any time the battery can't output enough power. Most of the attention is focused on old batteries, but cold weather can trigger it too. The original reason for the change was to deal with new phones with plenty of battery power remaining abruptly shutting off in winter weather. The phones wouldn't turn on again until you got them indoors in warmer air, at which point they'd realize they had plenty of power remaining.
They didn't make it configurable because their main concern was making sure people outdoors with ice & snow on the ground had functional phones.
Yep. And if Tim Cook wants to make an impression, he'd let users make their own decisions about what version of iOS they want to run, and give them the ability to side-load apps. This is just simple pandering in an attempt to avoid regulation.
1. You are free to run whatever version of iOS you want to LEAVE on your Device (there actually are NO "Forced Upgrades"). But, I will CERTAINLY agree that you SHOULD be allowed to "Downgrade" to an earlier version of iOS, if you Upgrade and then decide it doesn't suit you or your Device. But, that's why I never Upgrade an older Device until I let a few months go by to see what the performance issues, if any, affect those who do Upgrade. For example, I am "avoiding" Upgrading my iPhone 6 Plus to iOS 11, because of reports of performance issues with iPhone 6 and iOS 11.
2. You have been able to Side-Load ANY App you want on an non-jailbroken iOS Device running iOS 8 or later, using a couple of different methods:
a. If you have a Mac, you can use XCode to Compile and Install any number of "Open Source" iOS Apps written in Swift and Obj-C (and possibly other languages) sprayed all over the intarwebs (or, uh, you can WRITE your Own!). XCode is a Free Download (again, if you already have a Mac), and you only need to be a Registered Developer if you are going to submit your Glorious App to the App Store.
Slashdotters should be familiar with this distribution method, because it is PRECISELY how thousands of Open Source packages are distributed for Linux and other platforms.
And while you MUST use XCode, due to Code-Signing Requirements to submit to the App Store, (and also because it is probably still the best overall IDE for iOS Development), there ARE a few non-XCode iOS Development toolchains available. Caveat: I know NOTHING about these, what platforms they run on/support, etc. But here they are:
b. Using the Freeware Cydia Impactor utility, you can use a Mac or Windows (and maybe Linux?) PC to Install pre-compiled ".ipa" Files, WITHOUT needing to Jailbreak the iPhone... Then, all the User has to do is "Trust This Publisher" ONE TIME, and VOILA! The onus is on the USER (just like any good Slashdotter would want, right?) to decide whether they want to do this...
What a well reasoned posting, I especially like the respectful way you describe the people involved in a system you have no f-ing clue how it operates.
And no, that thinking isn't the problem which should be obvious if you spent some seconds thinking about it - assuming you have an IQ higher than an amoeba.
Speaking of respectful. Wanna talk about fail safe systems? Use the big words - I might just understand a lot more than you think I do.
There's your challenge, Accepted? Prove that a software only system is fail safe.
Ask the people aboard Flight 800.
Oh, wait...
And the Airbus too. Remember the early flight where the computer insisted that the plane fly below treetop level? "Fortunately" there were not that many on board.
Ot the one over in Europe where there was a strike that damaged thte engines on takeoff? Yeah, the SOP is to reduce power to as low as possible and return to land the plane while you still have engines. But apparently pilots would often throttle back shortly after takeoff to lower noise level in nearby developments. Well, that was considered bad by some folk, so they inserted some new software that wouldn't allow you to throttle back. You could play with the throttle all you want, but it didn't matter. They didn't bother to tell the pilots either. So the poor schmedlocks were desperately trying to reduce engine RPMs to save the engines enough to land, while the computer destroyed them by running at full power. They crashed in a field a few miles from the airport. Fortunately no one was killed. There were plenty of injuries though.
Niiiice. I hadn't heard about that last one. Need to watch more "Air Disasters", I guess, LOL!
And we both failed to mention the first failure of the Windows XP-based Aegis missle system, which splashed a commercial airliner in the Mediterranean (can't remember the number) because it didn't know how to do IFOF with a civilian aircraft.
Hey, it's probably a Windows-based system. We're lucky it didn't just decide to do a "Critical Update" at that moment!
I heard on one news report that the reason it took so long to cancel the Alert was that the Application that was supposed to do that "wasn't loaded"
(Now was it CANCEL.EXE, OR CANCEL1.EXE...?)
It is REALLY amazing we haven't had a bug-related missle launch in all this time...
We'ce come so close to accidentally incinerating ourselves on multiple occasions. Sensors fail, computers have software issues. In these cases, a human managed to believe something was askew when the computers were skwacking at them to start WW3. The scariest one was the Soviet satellite problem where it insisted the US had launched 5 nuc tipped missiles, and the funniest Strangelovian moment was when we almost ednded th eworld as we know it when a moonrise over Norway became a Soviet missile launch. https://www.nytimes.com/2018/0... Seriously, North Korea has nothing on the Nuclear Follies.
But to be serious, we might be in a situation now where caution won't be exercised. We have NK and the Present Occupant in a weenie waving contest, and said occupant does seem to want to use these big boys, which might cement his position in history pretty solid. So I for one, take accidental incoming missile strike oppsies pretty seriously, just for the potential escalation. It isn't likely to happen, a reality check should show no launch signatures, but these are not normal times.
Yep, I've heard about all of those foibles.
And yes, this isn't the time to have President Itchy-Trigger-Finger misguided by a flock of geese...
You need a mechanical physical switch with a switch guard. The very fact that an actual alert would be triggered by a menu item, indicates a completely incompetent design. I seldom call for people's jobs, but I'll make an exception in this case..
I thought the same thing about the keyswitch/switchgaurd.
But even a simple, glaring-red "ARE YOU SURE?!?" Confirmation Dialog would have probably prevented this frickin' FIASCO!!!
Probably. But it's still a computer driven thing, and if there is one thing I've learned it's that peoople trust computers too much. If they really worked all that well, they'd be the ones launching missiles automatically, no human intervention needed.
If you had such a switch, pushing it would have to be part of the test. Otherwise you've created a single point of failure that causes the live function to fail even though the test psses - and you don't find out until the missiles are inbound.
And the keyboard and left mouse button are also "Single Points of Failure", and the Display is a "Single Point of Failure", and the Power Supply is (probably) a "Single Point of Failure", etc, etc.
Removing the physical switch in the name of eliminating a "Single Point of Failure" is false reassurance.
I am old enough to remember that ConelRad snafu. That was like 1968, right? Pretty amazing something like that has only happened twice since the early 1950s...
The larger blame lies with the government and the (I hate the term, but it's so applicable here.) sheeple who call for this sort of a warning system.
There is no legitimate reason to have this sort of warning in place. None! North Korea has established that it can hit the ocean with its missiles most of the time. (They took out a neighborhood in one of their cities within the last 6 months!) Until North Korea is a) demonstrating that it can actually get an ICBM within 100 miles of its intended target, and b) is actively threatening to blow up parts of the US, it's insane fear mongering to have such a system in place.
I just don't understand how we got to a place where a sizable percent of the population of the US lives in daily fear of highly improbable shit. It's so utterly stupid, and unfortunately, these dumbasses vote in dumbasses who play on these fears.
Any suggestions for what we replace "the land of the free and the home of the brave" with?
So, we wait until they DO have that capabilty, and THEN start developing a warning system?
What a well reasoned posting, I especially like the respectful way you describe the people involved in a system you have no f-ing clue how it operates.
And no, that thinking isn't the problem which should be obvious if you spent some seconds thinking about it - assuming you have an IQ higher than an amoeba.
Speaking of respectful. Wanna talk about fail safe systems? Use the big words - I might just understand a lot more than you think I do.
There's your challenge, Accepted? Prove that a software only system is fail safe.
You are incorrect about a mechanical switch/guard. We are well past that era. What we need is someone other than Homer J. Simpson level people manning the system.
Your thinking is exactly what produced this system. Physical switches are so 1968! We can trigger the alert through a menu, and since we need a shortcut we'll use Ctrl+D so it will be easy.
So anyhow, the situation stands in evidence as to how software people and pus dripping edge folk produce failures.Deal with it.
Hey, it's probably a Windows-based system. We're lucky it didn't just decide to do a "Critical Update" at that moment!
I heard on one news report that the reason it took so long to cancel the Alert was that the Application that was supposed to do that "wasn't loaded"
(Now was it CANCEL.EXE, OR CANCEL1.EXE...?)
It is REALLY amazing we haven't had a bug-related missle launch in all this time...
Another aspect of this is that it is apparently just as easy to accidentally select the test option instead of the actual alert option. If a shift change is enough to mix these up, in an actual emergency an operator could easily end up thinking he sent an alert out when he really just triggered a test.
You need a mechanical physical switch with a switch guard. The very fact that an actual alert would be triggered by a menu item, indicates a completely incompetent design. I seldom call for people's jobs, but I'll make an exception in this case..
I thought the same thing about the keyswitch/switchgaurd.
But even a simple, glaring-red "ARE YOU SURE?!?" Confirmation Dialog would have probably prevented this frickin' FIASCO!!!
My PIN is four digits, although I can set it to be longer.
I don't trust data that's only in one place, particularly if I that place is normally my shirt pocket. I keep it backed up.
The problem I usually have with passphrases is that, while I can remember it, I have trouble remembering little details. Did I capitalize this? How many spaces after the period, or was that a semicolon?
That's EXACTLY why my Apple ][ disk encryption source disk is still "safe" from me. I used a Firesign Theatre phrase I knew as my passphrase, but could never reconstruct the punctuation!
Want to type a passphrase on an iPhone keyboard? Go ahead. The phone will be very secure since nobody including you will be able to activate it.
Under Touch ID and Passcode on a phone, you can specify that the phone will be wiped after ten tries to unlock it. That means an attacker has a 1% chance of guessing a random passcode before the phone is wiped. If that isn't sufficient, use a longer passcode.
By the way, they are now 6 characters/digits, making it even less likely.
And I agree, the longer and more involved you make a passphrase, the less it is advisable to have the "10 tries" feature enabled, or.... Whoops!!! Hope you had an iCloud Backup!!!
Al long, long time ago, I was messing around with a disk-encryption thing I wrote for the Apple ][. It allowed for an up to 32 character Alphanumeric passphrase. So, after I got it working, I decided to test it out... On my Source Code disk for the Encryption Code!
After about 40 years, It's STILL safe... From me. (D'oh!)
While passphrases are potentially better, I once found out that only the first few letters of a password I was using were significant. Whoops! This may not be true for the Apple version, but don't rely on it without experimenting.
As much as everyone likes to find every little fault with Apple, I think we would have heard something by now...
Courts can order you to unlock your phone, which means that the FBI is talking about investigations, not prosecutions. I suppose it depends on the investigation; if the phone contains the location someone in North America of a nuclear device set to explode in the next hour, then it might be great if the device got unlocked. Google et al. just cooperate with law enforcement; Apple has opted not to give itself a back door so it does not have to deal with the drama. Public opinion might change after the mushroom cloud however.
Read his comments with a huge grain of salt. Either he is so ignorant of crypto that he thinks that raising the number of iterations is genius rather than normal practice, or he is intentionally making outlandish statements that are calculated to sway public opinion. It seems obvious that it's the latter, and it will probably work.
Speaking of public opinion, if I were in Tim Cooks position, I would hold a YouTube live stream and call this FBI agent out personally.
Let the FBI stand up there and rant and rave about how unbreakable Apple security is. Let the FBI bitch and moan about hacking attempts on Apple hardware being very difficult.
Then Tim will stand up and ask one simple question; "Why is it hard for hackers to break into your encryption?"
The FBI will provide an obvious answer, to which Tim will reply in front of the world watching, "Thank you for confirming why the fuck Apple takes security seriously." *drops mic*
Yeah, I was thinking the same thing. I know there's a lot of idiots posting about the delay between attempts, but cracking a password doesn't work that way. You dump the data off the device, and then on a separate computer running the same algorithm you pound it as hard as you can as quickly as you can (hence why increasing from 10,000 rounds to 10,000,000 rounds would significantly slow cracking attempts). Delays work fine on remote systems you control, but are useless in a true cracking environment.
It's common to make the number of rounds large enough that on device it takes a second or so to complete, but 18 seconds on a cracking PC would probably be nearly a minute on device. That claim doesn't smell right.
speed at which one could brute-force passwords went from 45 attempts a second to one every 18 seconds
What? Say again? I'm pretty sure my iPhone doesn't take 18 seconds to verify my password. That would make logging in really slow.
No. After you start missing too many PW guesses, it starts increasing the delay between attempts, making it harder and harder to brute-force a PW, even if you DON'T have the "Erase after 10 failed attempts" option enabled.
What these people forget is that average people use these devices to do online banking/shopping/bill pay and that a lost or stolen device that doesn't have good encryption is just another way identity theft and fraud can happen. If protecting the people from fraud and identity theft that costs it's victims over $15 billion a year isn't a priority for these people then they shouldn't be in law enforcement.
It's not law enforcement that makes me want to keep my phone encrypted and password protected it's all the thieves and fraud.
I don't buy for a second that Apple care more about privacy out of the purity of their hearts. But their business model allows them to deliver on that front should they wish to, and lately their market (the users) gives them reason to wish so.
Well, they do seem to have given it a lot of thought with the relatively recent emergency feature you can enable that will erase all data on the phone after 10 failed passcode attempts.
That's not THAT "recent". But the "Panic Lock" feature is OBVIOUSLY aimed at protecting Privacy from the USER's Point-Of-View, be it from LEOs or the guy with the XKCD password-wrench.
Maybe this is just me, but government/intelligence agencies repeating so many times the message "Apple is the most secure" makes me thing: they already have an pre-cracked encryption and are trying to enforce this devices between his "enemies".
If they have a pre-cracked solution for iOS devices, think how much EASIER it would be to crack the most insecure mobile OS on the planet, which just so happens to be the most prevalent, too.
*this* If you have any indication that you may be a person of interest, either by activity or location, then you should *not* be using biometric locking on your phone at all. Panic lock is for when you don't expect that you are of interest, but suddenly find you may be. Note that once you're detained SOP for police would preclude you from being able to lock your phone, and in fact attempting to do so could get you shot. (reaching into your pocket == going for a gun).
Apple made the Panic Lock fast and easy enough that MOST people could manage to do it BEFORE being detained.
That being said, I agree: If you EXPECT to be hassled/detained, then by all means, not only use a Passcode, make it a passPHRASE > 4 characters. You can use up to 52 (IIRC) alphanumeric characters for an iOS passphrase. Let them chew on THAT!
Slashdot Mirror
Here’s the problem I have with this whole story. If the reason Apple provided explained the situation 100%, then we should have been hearing reports of older iPhones suddenly crashing at ~30% battery charge for years. But we didn’t... the issue only started rearing it’s head after iOS 10.x came around.
So why didn’t older iPhones have this problem with iOS 9, or 8, or earlier?
Because, as the CPU/GPU speed/number of cores, etc. went up in models that happened to be released at the same time as those versions of iOS, the ability for those systems to MOMENTARILY draw enough power to cause a dip in battery-voltage deliverable to the system (and thus a power-management panic) increased to the point where it wasn't as rare of an occurence as it once was.
The issue isn't about how long the battery lasts. It's about how much power the battery can supply at a given moment. There's a huge variance in how much power the phone needs depending on what you're doing at the moment. Accessing flash memory, enabling GPS/camera/bluetooth, downloading data, stressing the CPU, are all things that will make the power draw go up. You need to make sure the battery can handle the power spikes. If the battery can't handle the load, the phone just shuts off with no warning.
The update slows the phone down any time the battery can't output enough power. Most of the attention is focused on old batteries, but cold weather can trigger it too. The original reason for the change was to deal with new phones with plenty of battery power remaining abruptly shutting off in winter weather. The phones wouldn't turn on again until you got them indoors in warmer air, at which point they'd realize they had plenty of power remaining.
They didn't make it configurable because their main concern was making sure people outdoors with ice & snow on the ground had functional phones.
EXACTLY!!!
Mod Parent Up.
Yep. And if Tim Cook wants to make an impression, he'd let users make their own decisions about what version of iOS they want to run, and give them the ability to side-load apps. This is just simple pandering in an attempt to avoid regulation.
1. You are free to run whatever version of iOS you want to LEAVE on your Device (there actually are NO "Forced Upgrades"). But, I will CERTAINLY agree that you SHOULD be allowed to "Downgrade" to an earlier version of iOS, if you Upgrade and then decide it doesn't suit you or your Device. But, that's why I never Upgrade an older Device until I let a few months go by to see what the performance issues, if any, affect those who do Upgrade. For example, I am "avoiding" Upgrading my iPhone 6 Plus to iOS 11, because of reports of performance issues with iPhone 6 and iOS 11.
2. You have been able to Side-Load ANY App you want on an non-jailbroken iOS Device running iOS 8 or later, using a couple of different methods:
a. If you have a Mac, you can use XCode to Compile and Install any number of "Open Source" iOS Apps written in Swift and Obj-C (and possibly other languages) sprayed all over the intarwebs (or, uh, you can WRITE your Own!). XCode is a Free Download (again, if you already have a Mac), and you only need to be a Registered Developer if you are going to submit your Glorious App to the App Store.
Slashdotters should be familiar with this distribution method, because it is PRECISELY how thousands of Open Source packages are distributed for Linux and other platforms.
Here's a list on Github:
https://github.com/dkhamsing/o...
And while you MUST use XCode, due to Code-Signing Requirements to submit to the App Store, (and also because it is probably still the best overall IDE for iOS Development), there ARE a few non-XCode iOS Development toolchains available. Caveat: I know NOTHING about these, what platforms they run on/support, etc. But here they are:
https://www.jetbrains.com/objc...
https://www.xojo.com/
https://www.visualstudio.com/v...
https://coderunnerapp.com/
b. Using the Freeware Cydia Impactor utility, you can use a Mac or Windows (and maybe Linux?) PC to Install pre-compiled ".ipa" Files, WITHOUT needing to Jailbreak the iPhone... Then, all the User has to do is "Trust This Publisher" ONE TIME, and VOILA! The onus is on the USER (just like any good Slashdotter would want, right?) to decide whether they want to do this...
http://www.cydiaimpactor.com/
Here's a list of some sites that host free iOS .ipa Files:
https://www.gocydia.com/free-i...
BOTH of these methods have been available and officially-supported since iOS 8 was released in September, 2014.
But by all means, do keep up your mindless Apple-Hatred.
Oh, and you Apple Haters and other Slashtards can ALL STFU about "Walled Garden", FOREVER, got it?
What a well reasoned posting, I especially like the respectful way you describe the people involved in a system you have no f-ing clue how it operates.
And no, that thinking isn't the problem which should be obvious if you spent some seconds thinking about it - assuming you have an IQ higher than an amoeba.
Speaking of respectful. Wanna talk about fail safe systems? Use the big words - I might just understand a lot more than you think I do.
There's your challenge, Accepted? Prove that a software only system is fail safe.
Ask the people aboard Flight 800.
Oh, wait...
And the Airbus too. Remember the early flight where the computer insisted that the plane fly below treetop level? "Fortunately" there were not that many on board.
Ot the one over in Europe where there was a strike that damaged thte engines on takeoff? Yeah, the SOP is to reduce power to as low as possible and return to land the plane while you still have engines. But apparently pilots would often throttle back shortly after takeoff to lower noise level in nearby developments. Well, that was considered bad by some folk, so they inserted some new software that wouldn't allow you to throttle back. You could play with the throttle all you want, but it didn't matter. They didn't bother to tell the pilots either. So the poor schmedlocks were desperately trying to reduce engine RPMs to save the engines enough to land, while the computer destroyed them by running at full power. They crashed in a field a few miles from the airport. Fortunately no one was killed. There were plenty of injuries though.
Niiiice. I hadn't heard about that last one. Need to watch more "Air Disasters", I guess, LOL!
And we both failed to mention the first failure of the Windows XP-based Aegis missle system, which splashed a commercial airliner in the Mediterranean (can't remember the number) because it didn't know how to do IFOF with a civilian aircraft.
Hey, it's probably a Windows-based system. We're lucky it didn't just decide to do a "Critical Update" at that moment!
I heard on one news report that the reason it took so long to cancel the Alert was that the Application that was supposed to do that "wasn't loaded"
(Now was it CANCEL.EXE, OR CANCEL1.EXE...?)
It is REALLY amazing we haven't had a bug-related missle launch in all this time...
We'ce come so close to accidentally incinerating ourselves on multiple occasions. Sensors fail, computers have software issues. In these cases, a human managed to believe something was askew when the computers were skwacking at them to start WW3. The scariest one was the Soviet satellite problem where it insisted the US had launched 5 nuc tipped missiles, and the funniest Strangelovian moment was when we almost ednded th eworld as we know it when a moonrise over Norway became a Soviet missile launch. https://www.nytimes.com/2018/0... Seriously, North Korea has nothing on the Nuclear Follies.
But to be serious, we might be in a situation now where caution won't be exercised. We have NK and the Present Occupant in a weenie waving contest, and said occupant does seem to want to use these big boys, which might cement his position in history pretty solid. So I for one, take accidental incoming missile strike oppsies pretty seriously, just for the potential escalation. It isn't likely to happen, a reality check should show no launch signatures, but these are not normal times.
Yep, I've heard about all of those foibles.
And yes, this isn't the time to have President Itchy-Trigger-Finger misguided by a flock of geese...
You need a mechanical physical switch with a switch guard. The very fact that an actual alert would be triggered by a menu item, indicates a completely incompetent design. I seldom call for people's jobs, but I'll make an exception in this case..
I thought the same thing about the keyswitch/switchgaurd.
But even a simple, glaring-red "ARE YOU SURE?!?" Confirmation Dialog would have probably prevented this frickin' FIASCO!!!
Probably. But it's still a computer driven thing, and if there is one thing I've learned it's that peoople trust computers too much. If they really worked all that well, they'd be the ones launching missiles automatically, no human intervention needed.
Yup.
If you had such a switch, pushing it would have to be part of the test. Otherwise you've created a single point of failure that causes the live function to fail even though the test psses - and you don't find out until the missiles are inbound.
And the keyboard and left mouse button are also "Single Points of Failure", and the Display is a "Single Point of Failure", and the Power Supply is (probably) a "Single Point of Failure", etc, etc.
Removing the physical switch in the name of eliminating a "Single Point of Failure" is false reassurance.
I am old enough to remember that ConelRad snafu. That was like 1968, right? Pretty amazing something like that has only happened twice since the early 1950s...
Bingo! "Sokath, his eyes opened"
Temba, at rest.
The larger blame lies with the government and the (I hate the term, but it's so applicable here.) sheeple who call for this sort of a warning system.
There is no legitimate reason to have this sort of warning in place. None! North Korea has established that it can hit the ocean with its missiles most of the time. (They took out a neighborhood in one of their cities within the last 6 months!) Until North Korea is a) demonstrating that it can actually get an ICBM within 100 miles of its intended target, and b) is actively threatening to blow up parts of the US, it's insane fear mongering to have such a system in place.
I just don't understand how we got to a place where a sizable percent of the population of the US lives in daily fear of highly improbable shit. It's so utterly stupid, and unfortunately, these dumbasses vote in dumbasses who play on these fears.
Any suggestions for what we replace "the land of the free and the home of the brave" with?
So, we wait until they DO have that capabilty, and THEN start developing a warning system?
You are frickin' waste of DNA.
What a well reasoned posting, I especially like the respectful way you describe the people involved in a system you have no f-ing clue how it operates.
And no, that thinking isn't the problem which should be obvious if you spent some seconds thinking about it - assuming you have an IQ higher than an amoeba.
Speaking of respectful. Wanna talk about fail safe systems? Use the big words - I might just understand a lot more than you think I do.
There's your challenge, Accepted? Prove that a software only system is fail safe.
Ask the people aboard Flight 800.
Oh, wait...
You are incorrect about a mechanical switch/guard. We are well past that era. What we need is someone other than Homer J. Simpson level people manning the system.
Your thinking is exactly what produced this system. Physical switches are so 1968! We can trigger the alert through a menu, and since we need a shortcut we'll use Ctrl+D so it will be easy.
So anyhow, the situation stands in evidence as to how software people and pus dripping edge folk produce failures.Deal with it.
Hey, it's probably a Windows-based system. We're lucky it didn't just decide to do a "Critical Update" at that moment!
I heard on one news report that the reason it took so long to cancel the Alert was that the Application that was supposed to do that "wasn't loaded"
(Now was it CANCEL.EXE, OR CANCEL1.EXE...?)
It is REALLY amazing we haven't had a bug-related missle launch in all this time...
Another aspect of this is that it is apparently just as easy to accidentally select the test option instead of the actual alert option. If a shift change is enough to mix these up, in an actual emergency an operator could easily end up thinking he sent an alert out when he really just triggered a test.
No shit.
You need a mechanical physical switch with a switch guard. The very fact that an actual alert would be triggered by a menu item, indicates a completely incompetent design. I seldom call for people's jobs, but I'll make an exception in this case..
I thought the same thing about the keyswitch/switchgaurd.
But even a simple, glaring-red "ARE YOU SURE?!?" Confirmation Dialog would have probably prevented this frickin' FIASCO!!!
My PIN is four digits, although I can set it to be longer.
I don't trust data that's only in one place, particularly if I that place is normally my shirt pocket. I keep it backed up.
The problem I usually have with passphrases is that, while I can remember it, I have trouble remembering little details. Did I capitalize this? How many spaces after the period, or was that a semicolon?
That's EXACTLY why my Apple ][ disk encryption source disk is still "safe" from me. I used a Firesign Theatre phrase I knew as my passphrase, but could never reconstruct the punctuation!
Want to type a passphrase on an iPhone keyboard? Go ahead. The phone will be very secure since nobody including you will be able to activate it.
Under Touch ID and Passcode on a phone, you can specify that the phone will be wiped after ten tries to unlock it. That means an attacker has a 1% chance of guessing a random passcode before the phone is wiped. If that isn't sufficient, use a longer passcode.
By the way, they are now 6 characters/digits, making it even less likely.
And I agree, the longer and more involved you make a passphrase, the less it is advisable to have the "10 tries" feature enabled, or.... Whoops!!! Hope you had an iCloud Backup!!!
Al long, long time ago, I was messing around with a disk-encryption thing I wrote for the Apple ][. It allowed for an up to 32 character Alphanumeric passphrase. So, after I got it working, I decided to test it out... On my Source Code disk for the Encryption Code!
After about 40 years, It's STILL safe... From me. (D'oh!)
While passphrases are potentially better, I once found out that only the first few letters of a password I was using were significant. Whoops! This may not be true for the Apple version, but don't rely on it without experimenting.
As much as everyone likes to find every little fault with Apple, I think we would have heard something by now...
Courts can order you to unlock your phone, which means that the FBI is talking about investigations, not prosecutions. I suppose it depends on the investigation; if the phone contains the location someone in North America of a nuclear device set to explode in the next hour, then it might be great if the device got unlocked. Google et al. just cooperate with law enforcement; Apple has opted not to give itself a back door so it does not have to deal with the drama. Public opinion might change after the mushroom cloud however.
Risk is the price of freedom, fucker.
Read his comments with a huge grain of salt. Either he is so ignorant of crypto that he thinks that raising the number of iterations is genius rather than normal practice, or he is intentionally making outlandish statements that are calculated to sway public opinion. It seems obvious that it's the latter, and it will probably work.
Speaking of public opinion, if I were in Tim Cooks position, I would hold a YouTube live stream and call this FBI agent out personally.
Let the FBI stand up there and rant and rave about how unbreakable Apple security is. Let the FBI bitch and moan about hacking attempts on Apple hardware being very difficult.
Then Tim will stand up and ask one simple question; "Why is it hard for hackers to break into your encryption?"
The FBI will provide an obvious answer, to which Tim will reply in front of the world watching, "Thank you for confirming why the fuck Apple takes security seriously." *drops mic*
Oh, yeah!
Put it up on the Apple Events channel TODAY!!!!
Yeah, I was thinking the same thing. I know there's a lot of idiots posting about the delay between attempts, but cracking a password doesn't work that way. You dump the data off the device, and then on a separate computer running the same algorithm you pound it as hard as you can as quickly as you can (hence why increasing from 10,000 rounds to 10,000,000 rounds would significantly slow cracking attempts). Delays work fine on remote systems you control, but are useless in a true cracking environment.
It's common to make the number of rounds large enough that on device it takes a second or so to complete, but 18 seconds on a cracking PC would probably be nearly a minute on device. That claim doesn't smell right.
Doesn't work that way with the Secure Enclave.
speed at which one could brute-force passwords went from 45 attempts a second to one every 18 seconds
What? Say again?
I'm pretty sure my iPhone doesn't take 18 seconds to verify my password. That would make logging in really slow.
No. After you start missing too many PW guesses, it starts increasing the delay between attempts, making it harder and harder to brute-force a PW, even if you DON'T have the "Erase after 10 failed attempts" option enabled.
Good backup defense, IMHO.
What these people forget is that average people use these devices to do online banking/shopping/bill pay and that a lost or stolen device that doesn't have good encryption is just another way identity theft and fraud can happen. If protecting the people from fraud and identity theft that costs it's victims over $15 billion a year isn't a priority for these people then they shouldn't be in law enforcement.
It's not law enforcement that makes me want to keep my phone encrypted and password protected it's all the thieves and fraud.
Amen, brother!
That's EXACTLY what the LEOs don't get.
This difference has real consequences.
I don't buy for a second that Apple care more about privacy out of the purity of their hearts. But their business model allows them to deliver on that front should they wish to, and lately their market (the users) gives them reason to wish so.
Well, they do seem to have given it a lot of thought with the relatively recent emergency feature you can enable that will erase all data on the phone after 10 failed passcode attempts.
That's not THAT "recent". But the "Panic Lock" feature is OBVIOUSLY aimed at protecting Privacy from the USER's Point-Of-View, be it from LEOs or the guy with the XKCD password-wrench.
The Apple board is comprised largely of politicians and others with enough sway to get the FBI to give them free advertising like this.
Oh, please.
Maybe this is just me, but government/intelligence agencies repeating so many times the message "Apple is the most secure" makes me thing: they already have an pre-cracked encryption and are trying to enforce this devices between his "enemies".
If they have a pre-cracked solution for iOS devices, think how much EASIER it would be to crack the most insecure mobile OS on the planet, which just so happens to be the most prevalent, too.
IOW, you make ABSOLUTELY no sense.
*this*
If you have any indication that you may be a person of interest, either by activity or location, then you should *not* be using biometric locking on your phone at all.
Panic lock is for when you don't expect that you are of interest, but suddenly find you may be.
Note that once you're detained SOP for police would preclude you from being able to lock your phone, and in fact attempting to do so could get you shot. (reaching into your pocket == going for a gun).
Apple made the Panic Lock fast and easy enough that MOST people could manage to do it BEFORE being detained.
That being said, I agree: If you EXPECT to be hassled/detained, then by all means, not only use a Passcode, make it a passPHRASE > 4 characters. You can use up to 52 (IIRC) alphanumeric characters for an iOS passphrase. Let them chew on THAT!