What's going on is the FBI wants a precedent (and a firmware) that they can make apple use in other non-national-security cases. I have the viewpoint that if Apple didn't want to be subject to this, they should have designed the handset so that they couldn't "help" unlock it. The only reason Apple can resist in this case without getting killed in the press is that it is very unlikely that there is valuable data on this handset. (It's the gunman's work phone; he destroyed his personal phone.)
Why does apple get headlines for doing what they should have done in the first place? Anything else is a broken, insecure device. If the vendor has a backdoor, it's not secure, whether they allow the government to access it or not.
I see the second issue as exactly opposite to the first quote. A precedent in favor of the government on this case seems like a good way to ensure that hardware makers stop giving themselves access to their customers' devices, otherwise they will get showered with government orders. That is exactly what we want -- i.e. actual security, not pretend security at the changeable whim of the vendor. Apple, for this device model at least, seems to want to have its cake and eat it too. They want to themselves be able to subvert the security on their customers' devices but at the same time be able to tell the government that they can't do so. Sorry, that doesn't fly.
Yes! A vendor-held backdoor, or vendor ability to insert one after the fact, is the same security risk whether the government mandates it and can use it or not.
Or maybe we should all side against vendor-held backdoors. It shouldn't be Apple's or the government's decision whether or not to unlock an owner-locked handset.
Yep. My hope: 1. Apple resists until the supreme court says they must assist, 2. as a result, vendors make SECURE handsets that they have no ability to "help" unlock. Win for the customer! If Apple is not forced to help in this case, the customer (the owner of the device) LOSES because vendors can continue to make handsets "pretend secure" like this handset is. If the vendor has a backdoor or the ability to insert one without owner consent, it's not secure, just like if the government mandates a backdoor, it's not secure. Fortunately the handset vendors are already heading in the direction of actually secure devices, with some, including Apple I believe, already there.
I think Apple should have to "help" unlock it so that the hardware makers learn their lesson and make sure the handsets are actually secure. I don't think claiming that making a new firmware is an undue burden is going to hold up on appeal. As far as I have heard Apple has not claimed this is "hard", only that it undermines the security of their devices. But that horse is gone. If this device's security depended on Apple's non-cooperation with the government, it was never secure to begin with. To say it another way, if you don't want to be served with writs of assistance DON'T MAKE A DEVICE THAT YOU CAN UNLOCK, even theoretically. Just admit this device was, unfortunately, broken and move on. If, by some chance, in the future this precedent leads to the government being able to prohibit vendors from making secure devices, all the fits that Apple can throw were never going to stop that anyway.
The "social engineering" bit makes you wonder if Apple has done exactly this in other instances. So just lie to apple about the situation with some sufficiently sobby story and they'll open it.
Then before we start hating on google... are there similar vulnerabilities in their wipe-if-too-many-unlock-fails? If not then this whole apple/google comparison is a garbage headline grab. This sounds a lot more like apple trying to save face for a poor implementation while the FBI is trying to get something that can be used to crack a whole class of iOS devices. Neither of which has anything to do with google unless their branded handsets (not just any android handset) are similarly poorly designed. Still a big fight with the FBI, just nothing to do with google.
Being more cynical I worry that it is apple pretending to protect the user's information, when in fact they already gave it all up via iCloud. That benefits the FBI too, since ignorant people will think "oh I can trust apple because they put up that big fight against the FBI", when in fact they didn't, they just gave up the iCloud data based on a warrant.
Not sure why this is modded funny... Not on rockets, but on spacecraft. Lets demonstrate that we can put a person outside the van Allen belts in sufficient centrifugally generated gravity that after a couple of years they will still be not dead and able to walk in gravity. During that we can also demonstrate that we can get stuff back from Mars. After all that engineering is done, then we can worry about the state of mind of a person going to Mars and back.
No, if you want to send men all over the solar system, you develop infrastructure that doesn't live in a gravity well. Which, I believe, is what NASA is actually doing. Unfortunately "mission to some to be named asteroid the identity of which depends on when we have enough funding to do anything but build a useless congressional pork rocket project" doesn't have the same ring as "return to the moon".
We could actually see the shuttles go up and it was a once-a-week gifted pull-out class, so we were outside watching it directly. It looked really strange, with the contrail splitting and curving oddly, and we had to go back inside to figure what had happened. I vaguely recall being sent off to play while the teachers regained their composure. That, I think, was the worst possible launch to have an accident on -- but, for the same reasons, the pressure to launch on schedule was that much higher.
I believe PGP in this context is used for end-to-end security. If you intercept the message at one end, outside the encryption, then that isn't a PGP flaw. This sounds like the application on the device is not careful with plaintexts and keys in memory, and so the data and possibly the key can be recovered from a physical device. That is completely different from decrypting intercepted data. If, on the other hand, this BB contains a hardened chip that the key is never supposed to leave and they are able to recover the key, that is big news.
SpaceX is *investing* in testing landing to make future launches cost them less. Ironically, NASA wouldn't be allowed to do that because it is "not mission related" even though it is the biggest step forward in access to space in the last 30 years. This complaint about misuse of funds is almost a perfect demonstration for why NASA is better off buying launch service rather than hardware.
While I think that is true, it could also be that driverless cars come to a stop in an unfamiliar way due to how they are programmed. Try leaving an extra few yards between you and the car in front of you at a stoplight every time and see if you don't end up with someone scuffing your back bumper. The truth is that in traffic, decisions are not made based on the behavior of just the car in front of you. The driving algorithm may not be responding to traffic as a human would, even if the human is "rigorously following traffic rules".
Solution: fix income inequality. We don't need billionaires who can't figure out how to spend their money so they give it away. That capital should go to the middle class who will use it for something.
I agree. The problem is not UTC or leap seconds, it is that POSIX time ignores the existence of leap seconds. The more appropriate fix to me would be to redefine POSIX time as TAI. Or more accurately obsolete POSIX time so programmers are forced to choose between TAI and UTC. Who would ever have tried to convert from posix time to year/month/day/hour/minute without a library anyway?
Seems to me that unix (i.e. POSIX) time is what needs fixing. It ignores(!!) leap seconds by definition. (see here, or man 2 time.). Leap seconds are not uniquely addressable in posix time. The second repeats. Surely we can do better for the default standard.
Hopefully you realize that leap seconds are not "chosen by a standards body" per se, they are actually measurements of the slow-down of the earth's rotation and the standards body just decides how to schedule them. As another poster said, if you don't need to know the time of day, don't convert to UTC, just use a time standard that doesn't have leap seconds. The problem here is ignorant people who don't realize that time of day is not easily derivable from time-since-epoch. Changing from leap seconds to leap minutes just allows them to be ignorant longer, which I would argue is a bad thing.
Do the moduli need to be a pre-shared secret? (I don't think so) If not, why does the server not just compute them in the background and change periodically? That seems to be what is suggested in the first section of RFC 4419. Why wasn't that implemented?
Universities typically use endowments for the fixed-cost and facilities portions of their budgets, which is not student support. But, as a result, those costs do not need to be paid out of tuition. This means the number given in the summary, "endowment used for tuition etc" is meaningless because that is not what endowment is typically used for. This seems like a hit piece that is cherry-picking numbers to trump up a conclusion.
You realize that the whole point is that nobody should "invest" in a currency. It is basically part of the fed's mandate to keep inflation at such a level that people will not try to do that. And that it has been basically proven that preventing "investment" in currency is essential for macroeconomic stability.
Slashdot Mirror
What's going on is the FBI wants a precedent (and a firmware) that they can make apple use in other non-national-security cases. I have the viewpoint that if Apple didn't want to be subject to this, they should have designed the handset so that they couldn't "help" unlock it. The only reason Apple can resist in this case without getting killed in the press is that it is very unlikely that there is valuable data on this handset. (It's the gunman's work phone; he destroyed his personal phone.)
Why does apple get headlines for doing what they should have done in the first place? Anything else is a broken, insecure device. If the vendor has a backdoor, it's not secure, whether they allow the government to access it or not.
I don't feel like you're really thinking through what it means to have the resources of a national intelligence agency.
I see the second issue as exactly opposite to the first quote. A precedent in favor of the government on this case seems like a good way to ensure that hardware makers stop giving themselves access to their customers' devices, otherwise they will get showered with government orders. That is exactly what we want -- i.e. actual security, not pretend security at the changeable whim of the vendor. Apple, for this device model at least, seems to want to have its cake and eat it too. They want to themselves be able to subvert the security on their customers' devices but at the same time be able to tell the government that they can't do so. Sorry, that doesn't fly.
Yes! A vendor-held backdoor, or vendor ability to insert one after the fact, is the same security risk whether the government mandates it and can use it or not.
Or maybe we should all side against vendor-held backdoors. It shouldn't be Apple's or the government's decision whether or not to unlock an owner-locked handset.
Yep. My hope: 1. Apple resists until the supreme court says they must assist, 2. as a result, vendors make SECURE handsets that they have no ability to "help" unlock. Win for the customer! If Apple is not forced to help in this case, the customer (the owner of the device) LOSES because vendors can continue to make handsets "pretend secure" like this handset is. If the vendor has a backdoor or the ability to insert one without owner consent, it's not secure, just like if the government mandates a backdoor, it's not secure. Fortunately the handset vendors are already heading in the direction of actually secure devices, with some, including Apple I believe, already there.
I think Apple should have to "help" unlock it so that the hardware makers learn their lesson and make sure the handsets are actually secure. I don't think claiming that making a new firmware is an undue burden is going to hold up on appeal. As far as I have heard Apple has not claimed this is "hard", only that it undermines the security of their devices. But that horse is gone. If this device's security depended on Apple's non-cooperation with the government, it was never secure to begin with. To say it another way, if you don't want to be served with writs of assistance DON'T MAKE A DEVICE THAT YOU CAN UNLOCK, even theoretically. Just admit this device was, unfortunately, broken and move on. If, by some chance, in the future this precedent leads to the government being able to prohibit vendors from making secure devices, all the fits that Apple can throw were never going to stop that anyway.
The "social engineering" bit makes you wonder if Apple has done exactly this in other instances. So just lie to apple about the situation with some sufficiently sobby story and they'll open it.
Then before we start hating on google... are there similar vulnerabilities in their wipe-if-too-many-unlock-fails? If not then this whole apple/google comparison is a garbage headline grab. This sounds a lot more like apple trying to save face for a poor implementation while the FBI is trying to get something that can be used to crack a whole class of iOS devices. Neither of which has anything to do with google unless their branded handsets (not just any android handset) are similarly poorly designed. Still a big fight with the FBI, just nothing to do with google.
Being more cynical I worry that it is apple pretending to protect the user's information, when in fact they already gave it all up via iCloud. That benefits the FBI too, since ignorant people will think "oh I can trust apple because they put up that big fight against the FBI", when in fact they didn't, they just gave up the iCloud data based on a warrant.
Not sure why this is modded funny... Not on rockets, but on spacecraft. Lets demonstrate that we can put a person outside the van Allen belts in sufficient centrifugally generated gravity that after a couple of years they will still be not dead and able to walk in gravity. During that we can also demonstrate that we can get stuff back from Mars. After all that engineering is done, then we can worry about the state of mind of a person going to Mars and back.
No, if you want to send men all over the solar system, you develop infrastructure that doesn't live in a gravity well. Which, I believe, is what NASA is actually doing. Unfortunately "mission to some to be named asteroid the identity of which depends on when we have enough funding to do anything but build a useless congressional pork rocket project" doesn't have the same ring as "return to the moon".
We could actually see the shuttles go up and it was a once-a-week gifted pull-out class, so we were outside watching it directly. It looked really strange, with the contrail splitting and curving oddly, and we had to go back inside to figure what had happened. I vaguely recall being sent off to play while the teachers regained their composure. That, I think, was the worst possible launch to have an accident on -- but, for the same reasons, the pressure to launch on schedule was that much higher.
I believe PGP in this context is used for end-to-end security. If you intercept the message at one end, outside the encryption, then that isn't a PGP flaw. This sounds like the application on the device is not careful with plaintexts and keys in memory, and so the data and possibly the key can be recovered from a physical device. That is completely different from decrypting intercepted data. If, on the other hand, this BB contains a hardened chip that the key is never supposed to leave and they are able to recover the key, that is big news.
SpaceX is *investing* in testing landing to make future launches cost them less. Ironically, NASA wouldn't be allowed to do that because it is "not mission related" even though it is the biggest step forward in access to space in the last 30 years. This complaint about misuse of funds is almost a perfect demonstration for why NASA is better off buying launch service rather than hardware.
While I think that is true, it could also be that driverless cars come to a stop in an unfamiliar way due to how they are programmed. Try leaving an extra few yards between you and the car in front of you at a stoplight every time and see if you don't end up with someone scuffing your back bumper. The truth is that in traffic, decisions are not made based on the behavior of just the car in front of you. The driving algorithm may not be responding to traffic as a human would, even if the human is "rigorously following traffic rules".
Solution: fix income inequality. We don't need billionaires who can't figure out how to spend their money so they give it away. That capital should go to the middle class who will use it for something.
Better yet, we need to FIX POSIX time not mess up UTC. Leap seconds are currently not representable in posix time.
I agree. The problem is not UTC or leap seconds, it is that POSIX time ignores the existence of leap seconds. The more appropriate fix to me would be to redefine POSIX time as TAI. Or more accurately obsolete POSIX time so programmers are forced to choose between TAI and UTC. Who would ever have tried to convert from posix time to year/month/day/hour/minute without a library anyway?
According to this they already are.
Seems to me that unix (i.e. POSIX) time is what needs fixing. It ignores(!!) leap seconds by definition. (see here, or man 2 time.). Leap seconds are not uniquely addressable in posix time. The second repeats. Surely we can do better for the default standard.
Hopefully you realize that leap seconds are not "chosen by a standards body" per se, they are actually measurements of the slow-down of the earth's rotation and the standards body just decides how to schedule them. As another poster said, if you don't need to know the time of day, don't convert to UTC, just use a time standard that doesn't have leap seconds. The problem here is ignorant people who don't realize that time of day is not easily derivable from time-since-epoch. Changing from leap seconds to leap minutes just allows them to be ignorant longer, which I would argue is a bad thing.
Do the moduli need to be a pre-shared secret? (I don't think so) If not, why does the server not just compute them in the background and change periodically? That seems to be what is suggested in the first section of RFC 4419. Why wasn't that implemented?
Universities typically use endowments for the fixed-cost and facilities portions of their budgets, which is not student support. But, as a result, those costs do not need to be paid out of tuition. This means the number given in the summary, "endowment used for tuition etc" is meaningless because that is not what endowment is typically used for. This seems like a hit piece that is cherry-picking numbers to trump up a conclusion.
You realize that the whole point is that nobody should "invest" in a currency. It is basically part of the fed's mandate to keep inflation at such a level that people will not try to do that. And that it has been basically proven that preventing "investment" in currency is essential for macroeconomic stability.