It's always been my impression that Google is building a warehouse of profiles and the last thing they want is advertisers to ever access that info... Am I misunderstanding their business model?
IMO you're overstating Google's "aggressiveness", but you've got the business model right, and you're right that the last thing Google wants to do is give the data to advertisers. And, frankly, advertisers couldn't use it as effectively.
Or clock frequency/supply voltage attacks. If timed right one may be able to make the phone crash/do something else instead of counting the failed attempt.
Glitching attacks can work, but they're hit or miss, and I don't think the approach you suggest would work. The iOS 8 bug was that the failure counter was updated after the password was tested and the result returned, so just by cutting power very quickly after the failure the counter update could be prevented. The simple solution to this is to increment the failure counter *before* you check the password. If the check is successful, you then zero the counter. If not, cutting power or other glitching won't help because it was already updated.
Hmm. There is less information online that I'd have thought. In brief: RPMB is flash whose on-board controller has an embedded MAC key, which is pre-shared at the factory with the CPU. All write messages must be correctly MACed or they're rejected. Each message must include the current value of a counter which increments on every successful operation, so a valid write message can't be replayed. There's more to it, but that's sufficient here.
Also its not like quite expensive tamper resistant chips haven't been broken for a little more than shits n giggles, and full class breaks i may add. Simple zero memory features on most consumer devices is really pretty easy to get around for the simple reason that they are cheap, even when they have them. You want expensive security your not going to get in consumer devices.
Depends on the sophistication and level of dedication of the attacker. No you're never going to keep the NSA, GCHQ, Mossad, etc. out of a consumer device. Or probably even a grad student with lots of time, access to expensive equipment (e.g. electron force microscope) and a willingness to destructively disassemble devices and painstakingly scan tiny chip features and read out embedded keys. But you can stop anyone less dedicated and less well-equipped.
I don't know if Apple uses RPMB, but it's the most obvious way to prevent the attack you mention (which I assume you got from the ACLU-distributed article that mentions it, but maybe not). There are others.
For fucks sake its like a 4-6 digit pin. Hardly real security.
Whether a four-digit PIN is secure depends on the brute force mitigations in place. If there are none, sure, you can pop that in a fraction of a second. If the device will wipe after 10 consecutive failed attempts, you either need really good information about what the PIN might be, or you're not getting the data.
You don't have to break the encryption if you can subvert the code that counts the number of attempts, that could easily be done by altering one of the cpu instructions in the silicon or disabling it
Nope. You're talking about very fundamental instructions like increment, compare, load, store, etc. If you alter or break how one of them functions (not that it's at all obvious how you could do that), you'd break the CPU completely, making it unable to execute simple code.
Another way would be to replace the CPU with a custom emulator of the CPU which could step around the sequence for destruction
Nope. The emulator wouldn't have access to the key burned into the CPU, so it couldn't compute the key to test.
or simpler.. multiply the number of times by an arbitrarily chosen "factor".. or reset it to zero after each attempt.
It may or may not be possible to restore the counter value. The value is almost certainly protected against simple updates (e.g. with a message authentication code), but it may be possible to roll it back, assuming it's not stored in a Replay Protected Memory Block (RPMB), or similar. RPMB is special flash that requires every write to be signed, and the signature includes a counter value and is increased on each operation, so replaying an old write command won't work, and only a device with the signing key (which would be burned into the CPU) could produce a valid write signature.
Here are some approaches that would work:
1. Carefully peel the CPU apart until you find the silicon that stores the key. Extract it, then you can easily brute force the PIN to decrypt the data. This is attack requires a fair amount of expertise and it requires lots of methodical, painstaking work, but it would work.
2. Connect probes to the memory bus and record everything that goes on as you boot the device and attempt to verify one password. Odds are good that at some point the key is written to or read from DRAM, though it is possible that it is transferred directly from the permanent storage location (likely on-chip fuses) to a hardware crypto engine in the CPU, in which case you won't see it and this won't work.
3. Insert a DRAM multiplexer between the mainboard and DRAM. Boot the device, which will verify the software and copy it into RAM. Let the device go to sleep (which will put the DRAM in self-refresh mode). Flip the muxer so the DRAM isn't connected to the device any more, but is instead connected to your own CPU. Read out all of the RAM contents. You may find the key, in which case you can easily brute force the PIN. If not, just write the DRAM to alter the code to skip the incrementing of the failure counter, then flip the muxer back and proceed to manually brute force the PIN.
I could probably come up with a few more. Without a separate secure processor that has it's own onboard RAM and storage (like the newer iOS devices have), there are lots of attacks available.
Basically some hacker found that they could hook a device up the phones innards and just try brute forcing the 4-digit PIN and that if they cut all power to the device on a failed attempt quickly enough that the system wouldn't register the failed attempt and wipe the device.
I thought iOS 8 vulnerability was fixed in iOS 9. I don't think that's the attack they're using.
Yep. I just hope the answer isn't going to be making National Security Letters the new standard MO.
An NSL wouldn't help the FBI in a case like this. NSLs can only compel metadata in the company's possession. Apple doesn't possess the data on Farook's device, and so can't be ordered to extract and deliver the metadata.
I'm not talking about "technical" definitions, I'm talking about "useful" definitions. If the goal is to inform people of possibly-dangerous products, then omitting those created by mutation breeding isn't a minor oversight, it's missing most of the point.
Which is a good example how and why OSS works: It was found, documented, traced back (no sign of foul play) and fixed. What do you think would have happened in a commercial, closed library?
In commercial software it would be found, documented, traced back, and fixed. Documentation would be internal.
Not in the vast majority of companies. I've been a professional software engineer for better than 25 years, and I've worked for a lot of different companies. In almost none of them is there any focus at all on going back to identify and fix problems in existing code. It's always about the next product release, or the next customization request... what will bring in more money.
There are some exceptions, but they're mostly companies and products who are facing significant outside scrutiny. These days, I'm sure Cisco is spending a lot on internal security research, but only because they've been caught several times very publicly with their pants down, for example.
OSS isn't a panacea, obviously. But it does mean that when someone decides they do care enough to look, they can find the problems, and fix them.
Oh, and then re-create it for each of the next 200 phones the FBI wants into... making sure that no copies every leak, each time.
One possibility would be to unlock the phone, send an appropriate bill (some major six digit number), and see if they really want the next phone unlocked at that cost.
The FBI would just argue in court that Apple can't substantiate that cost, and get the court to find that they don't have to pay, or only have to pay a reduced amount. Especially for the nth device.
Slippery slope arguments are generally fallacious, but not always, and this case really is a slippery slope.
while a free market economy is much better at allocating scarce resources than any other method(especially government controlled or regulated economy), for a truly free market to work , there should be full information and perfect competition, impossible conditions.
True, and this is why GMO labeling is a bad idea, because it's misleading and therefore reduces the information available to buyers.
What makes it misleading is that the proposed labels only cover a tiny portion of the GMO products on the shelves. The labels only address GMOs produced by one specific method, gene splicing, and ignore all of the others produced by mutation breeding. Any logical analysis of the processes has to conclude that strains produced by gene splicing must be safer than those produced by drenching organisms in radiation and mutagenic chemicals to induce large numbers of random mutations, then selecting the offspring that appear to be safe and useful.
Thus, the GMO labels highlight the "risks" of consuming safer products and imply that other, more dangerous products, are the safe ones.
Regardless, if you'd rather pull the product than relabel it then you know in advance that your product can't survive with an accurate label. People are stupid, but tough - that's just the way the market is.
There's an assumption in this statement: That the label is accurate, in the sense that it usefully distinguishes the labeled product from all of the unlabeled products. Given that the discussion is about labeling only GMOs produced by gene splicing and not all of the other GMOs produced by mutation breeding, which is the process of showering organisms with radiation and/or mutagenic chemicals in order to induce large numbers of random mutations, from which those that appear safe and useful can be selected, that assumption of accuracy is false.
If we're going to label GMOs, we should label all GMOs, not just the ones created by the safest and most controlled method.
If they're happy with it, if it has advantages they can sell the consumers, then they should sell it to consumers on its advantages.
Why would you try to conceal GMO products from the consumer? It's confirmation that the makers of GMO products have something to hide!
I have no problem with labeling, as long as we make sure we label all the GMO products, not just the ones that resulted from gene splicing. We also need to label all of the products that resulted from mutation breeding, using radiation, transposons or mutagentic chemicals to cause large numbers of random mutations. Obviously, those products are much more dangerous than the ones created by carefully altering one tiny section of the organism's DNA.
Unfortunately, there's a problem: labeling the results of mutation breeding would require labeling virtually everything in the grocery store. Mutation breeding has been widely used for a century now, and most of the strains we currently eat were produced that way. So if we labeled accurately, the labels would be uninformative.
And this is why I actually oppose labeling. If accurate labels are uninformative, then inaccurate labels can have no value whatsoever.
If you want to add a label that says something useful related to the riskiness of eating an organism, perhaps the best thing to do is to identify the age of the strain. Something we've been eating for a thousand years is likely safe (not that there's anything that old in the grocery store). Something we've been eating for 50 years is less safe, but probably safer than something that just came into existence last year, in the sense that there's a better chance we've observed the negative effects.
So, if you want to label, I'd say label by the age of the strain, whether it was created by gene splicing, mutation breeding or "natural" selective breeding (which is only different from mutation breeding in that it relies on cosmic rays and other "natural" mutagens to provide the mutations for selection). What would really be ideal is to label with an estimate of the number of people who've eaten that strain without apparent harm, perhaps weighted by how long ago they ate it, in order to increase the odds that problems would have been observed.
That would be scientifically-accurate and useful information that you could put on a label.
So Apple just has to "un-exist" it when they are done. Develop and use it in a clean room, then destroy the contents of the room once they hand over the pin to the FBI, if it turns out that the FBI has a constitutional right to demand Apples assistance.
Oh, and then re-create it for each of the next 200 phones the FBI wants into... making sure that no copies every leak, each time.
This case isn't about Farook's phone. Everyone knows there's nothing of use on it anyway... anything of value would have been on one of his burner phones, which the FBI knows he had and knows he destroyed, not on the phone that he knew was being backed up to iCloud under an employer-owned account. This is all about the precedent. The FBI picked this phone because "terrorist!", but even they don't care about this one. It's all about the rest.
For example how exactly are you supposed to direct the car to a specific parking spot inside a garage?
Yep I'm sure the best and brightest minds in car automation haven't given this a moment's thought. What idiots!
The real question is... why do you care where your network-connected self-driving car parks? Let the damned thing figure it out by itself. Whey you need it, you don't go find it, you grab your phone and tell it to come to you.
For example how exactly are you supposed to direct the car to a specific parking spot inside a garage?
Why would you want to? Just get out and let the car figure out where to park. Or maybe tell it to go home. When you're ready to go, just use your phone to tell the car where to pick you up.
I can't imagine what leads Google to think they can actually solve EVERY problem an autonomous car will run into with the very first version.
This is very, very far from the first version.
Where exactly does that extraordinary self-confidence (hubris?) come from?
Several years and ~1.5 million miles of real-world testing.
That is, designers felt the damn thing didn't look futuristic enough if it still had a steering wheel and petals.
No, actually. The people working on it have explained at length why they took this step, and it derived from actual experience and testing. There are two problems with putting controls in a self-driving car. First, it makes people think that the car can get away with self-driving most of the time and expecting the human driver to take over when something bad happens. But Google's experience with early systems, given to employees to use with strict instructions to pay attention as though they were driving and be ready to take over showed that even people who understand the risks tend to put way too much faith in the system. This means that the system must be able to handle driving entirely on its own, because as soon as it looks remotely capable, people will let it.
The second problem with having controls is that drivers may actually try to take control when they think they know better than the car... and they'll do it with less understanding and less context and no idea why the car is doing what it's doing (because they really haven't been paying attention, and anyway aren't equipped with sensors that are nearly as good as the car's), and in so doing will do the *wrong* thing. Fundamentally, it's a very bad idea to divide control between two drivers. If the car is driving, the car should drive and the people should be passengers. The best way to enforce this view on designers and passengers alike is to remove the controls.
Because I program automation system, and one thing I do know is that Executives are so fucking fickle that they can not make a decision to save their own life. No A.I. on the planet will be able to handle an Executive or CEO.
CEO:"I do not like this system there are black bars on the screen."
A.I.: "you demanded we use a 16:10 projector on a 16:9 screen, you even used executive override protocol even though we told you they were incompatible and would have black bars"
CEO:" make it work without black bars"
A.I.: " we will have to change the screen or the projector, what do you prefer"
CEO:" Use what I wanted, make it work"
A.I.:"......... Illogical...... Murder...... Kill.... Destroy......."
Meh. Just scale it to fill. It'll be slightly stretched vertically, but not enough that most people (including the CEO) will notice.
For that matter, if the video that will be displayed is of the CEO, he may understand *exactly* what he's asking for, and the AI is just being dense. Maybe he wants the slight deformation of the video to make him look taller. Not so much that it's obvious, but enough that it may influence the perceptions of the viewers.
Soon, human beings will be the first living organism to cause self-obsolescence.
Not the first. The vast majority of species that have lived on Earth have caused self-obsolescence and died out as a result. We're just considering a different and more efficient route to this most normal of ends.
Health effects, whatever. I feel better when I can change positions every now and then. Sitting all day leaves me feeling tired and my back gets sore (yes, I've tried lots of different chairs). With a sit/stand desk I change positions every hour or two, switching between standing, sitting on a moderately-ergonomic desk chair and sitting on an exercise ball. The latter is actually fairly hard work to sustain for a long time, but I think my core has gotten stronger for doing it. Standing eventually makes my feet hurt. No one position is ideal, but changing it up seems to work great.
It might not be smart to quit if, while employed, they are under Apple's umbrella of legal protection. Alone in the wild, could employees with knowledge on how to crack the phone* be pressured to crack the phones?
If the design is any good -- and I'm quite sure it is -- then knowledge doesn't matter. What matters is possession of the Apple signing keys, and departing employees wouldn't get to take those with them.
* = "Hey, remember when Apple said phones couldn't be cracked? Ha, good times, good times. (cries in beer)"
All security is relative to a threat model, and when Apple said that they -- quite reasonably -- didn't consider Apple being ordered to sign weakened versions of their security software as part of their threat model.
I am wondering who will quit their 6-digit salary paying swanky job in the Silicon Valley, just because they do not agree with the law enforcement. Maybe 1 or 2 people with some screws loose upstairs, but no sane person would do such a thing.
Considering your integrity to be more important than your job -- even when you can easily get another just as good -- is insane. Got it.
Slashdot Mirror
It WORKED for thousands of years.
For suitable definitions of "worked". Personally, I don't want a monetary system that "works" that well.
It's always been my impression that Google is building a warehouse of profiles and the last thing they want is advertisers to ever access that info... Am I misunderstanding their business model?
IMO you're overstating Google's "aggressiveness", but you've got the business model right, and you're right that the last thing Google wants to do is give the data to advertisers. And, frankly, advertisers couldn't use it as effectively.
Google just up and opens 12 new datacenters, probably with 10k servers each.
I've been to some Google data centers. I doubt that any of them are that small.
Or clock frequency/supply voltage attacks. If timed right one may be able to make the phone crash/do something else instead of counting the failed attempt.
Glitching attacks can work, but they're hit or miss, and I don't think the approach you suggest would work. The iOS 8 bug was that the failure counter was updated after the password was tested and the result returned, so just by cutting power very quickly after the failure the counter update could be prevented. The simple solution to this is to increment the failure counter *before* you check the password. If the check is successful, you then zero the counter. If not, cutting power or other glitching won't help because it was already updated.
Well google gives nothing so perhaps not.
Hmm. There is less information online that I'd have thought. In brief: RPMB is flash whose on-board controller has an embedded MAC key, which is pre-shared at the factory with the CPU. All write messages must be correctly MACed or they're rejected. Each message must include the current value of a counter which increments on every successful operation, so a valid write message can't be replayed. There's more to it, but that's sufficient here.
Also its not like quite expensive tamper resistant chips haven't been broken for a little more than shits n giggles, and full class breaks i may add. Simple zero memory features on most consumer devices is really pretty easy to get around for the simple reason that they are cheap, even when they have them. You want expensive security your not going to get in consumer devices.
Depends on the sophistication and level of dedication of the attacker. No you're never going to keep the NSA, GCHQ, Mossad, etc. out of a consumer device. Or probably even a grad student with lots of time, access to expensive equipment (e.g. electron force microscope) and a willingness to destructively disassemble devices and painstakingly scan tiny chip features and read out embedded keys. But you can stop anyone less dedicated and less well-equipped.
I don't know if Apple uses RPMB, but it's the most obvious way to prevent the attack you mention (which I assume you got from the ACLU-distributed article that mentions it, but maybe not). There are others.
For fucks sake its like a 4-6 digit pin. Hardly real security.
Whether a four-digit PIN is secure depends on the brute force mitigations in place. If there are none, sure, you can pop that in a fraction of a second. If the device will wipe after 10 consecutive failed attempts, you either need really good information about what the PIN might be, or you're not getting the data.
You should learn about relay protected memory. I'd explain it but I'm on my phone.
Apple couldn't substantiate a six digit cost because it wouldn't cost that much. Not every time.
You don't have to break the encryption if you can subvert the code that counts the number of attempts, that could easily be done by altering one of the cpu instructions in the silicon or disabling it
Nope. You're talking about very fundamental instructions like increment, compare, load, store, etc. If you alter or break how one of them functions (not that it's at all obvious how you could do that), you'd break the CPU completely, making it unable to execute simple code.
Another way would be to replace the CPU with a custom emulator of the CPU which could step around the sequence for destruction
Nope. The emulator wouldn't have access to the key burned into the CPU, so it couldn't compute the key to test.
or simpler.. multiply the number of times by an arbitrarily chosen "factor".. or reset it to zero after each attempt.
It may or may not be possible to restore the counter value. The value is almost certainly protected against simple updates (e.g. with a message authentication code), but it may be possible to roll it back, assuming it's not stored in a Replay Protected Memory Block (RPMB), or similar. RPMB is special flash that requires every write to be signed, and the signature includes a counter value and is increased on each operation, so replaying an old write command won't work, and only a device with the signing key (which would be burned into the CPU) could produce a valid write signature.
Here are some approaches that would work:
1. Carefully peel the CPU apart until you find the silicon that stores the key. Extract it, then you can easily brute force the PIN to decrypt the data. This is attack requires a fair amount of expertise and it requires lots of methodical, painstaking work, but it would work.
2. Connect probes to the memory bus and record everything that goes on as you boot the device and attempt to verify one password. Odds are good that at some point the key is written to or read from DRAM, though it is possible that it is transferred directly from the permanent storage location (likely on-chip fuses) to a hardware crypto engine in the CPU, in which case you won't see it and this won't work.
3. Insert a DRAM multiplexer between the mainboard and DRAM. Boot the device, which will verify the software and copy it into RAM. Let the device go to sleep (which will put the DRAM in self-refresh mode). Flip the muxer so the DRAM isn't connected to the device any more, but is instead connected to your own CPU. Read out all of the RAM contents. You may find the key, in which case you can easily brute force the PIN. If not, just write the DRAM to alter the code to skip the incrementing of the failure counter, then flip the muxer back and proceed to manually brute force the PIN.
I could probably come up with a few more. Without a separate secure processor that has it's own onboard RAM and storage (like the newer iOS devices have), there are lots of attacks available.
Basically some hacker found that they could hook a device up the phones innards and just try brute forcing the 4-digit PIN and that if they cut all power to the device on a failed attempt quickly enough that the system wouldn't register the failed attempt and wipe the device.
I thought iOS 8 vulnerability was fixed in iOS 9. I don't think that's the attack they're using.
Yep. I just hope the answer isn't going to be making National Security Letters the new standard MO.
An NSL wouldn't help the FBI in a case like this. NSLs can only compel metadata in the company's possession. Apple doesn't possess the data on Farook's device, and so can't be ordered to extract and deliver the metadata.
I'm not talking about "technical" definitions, I'm talking about "useful" definitions. If the goal is to inform people of possibly-dangerous products, then omitting those created by mutation breeding isn't a minor oversight, it's missing most of the point.
Which is a good example how and why OSS works: It was found, documented, traced back (no sign of foul play) and fixed. What do you think would have happened in a commercial, closed library?
In commercial software it would be found, documented, traced back, and fixed. Documentation would be internal.
Not in the vast majority of companies. I've been a professional software engineer for better than 25 years, and I've worked for a lot of different companies. In almost none of them is there any focus at all on going back to identify and fix problems in existing code. It's always about the next product release, or the next customization request... what will bring in more money.
There are some exceptions, but they're mostly companies and products who are facing significant outside scrutiny. These days, I'm sure Cisco is spending a lot on internal security research, but only because they've been caught several times very publicly with their pants down, for example.
OSS isn't a panacea, obviously. But it does mean that when someone decides they do care enough to look, they can find the problems, and fix them.
Oh, and then re-create it for each of the next 200 phones the FBI wants into... making sure that no copies every leak, each time.
One possibility would be to unlock the phone, send an appropriate bill (some major six digit number), and see if they really want the next phone unlocked at that cost.
The FBI would just argue in court that Apple can't substantiate that cost, and get the court to find that they don't have to pay, or only have to pay a reduced amount. Especially for the nth device.
Slippery slope arguments are generally fallacious, but not always, and this case really is a slippery slope.
while a free market economy is much better at allocating scarce resources than any other method(especially government controlled or regulated economy), for a truly free market to work , there should be full information and perfect competition, impossible conditions.
True, and this is why GMO labeling is a bad idea, because it's misleading and therefore reduces the information available to buyers.
What makes it misleading is that the proposed labels only cover a tiny portion of the GMO products on the shelves. The labels only address GMOs produced by one specific method, gene splicing, and ignore all of the others produced by mutation breeding. Any logical analysis of the processes has to conclude that strains produced by gene splicing must be safer than those produced by drenching organisms in radiation and mutagenic chemicals to induce large numbers of random mutations, then selecting the offspring that appear to be safe and useful.
Thus, the GMO labels highlight the "risks" of consuming safer products and imply that other, more dangerous products, are the safe ones.
Regardless, if you'd rather pull the product than relabel it then you know in advance that your product can't survive with an accurate label. People are stupid, but tough - that's just the way the market is.
There's an assumption in this statement: That the label is accurate, in the sense that it usefully distinguishes the labeled product from all of the unlabeled products. Given that the discussion is about labeling only GMOs produced by gene splicing and not all of the other GMOs produced by mutation breeding, which is the process of showering organisms with radiation and/or mutagenic chemicals in order to induce large numbers of random mutations, from which those that appear safe and useful can be selected, that assumption of accuracy is false.
If we're going to label GMOs, we should label all GMOs, not just the ones created by the safest and most controlled method.
If they're happy with it, if it has advantages they can sell the consumers, then they should sell it to consumers on its advantages.
Why would you try to conceal GMO products from the consumer? It's confirmation that the makers of GMO products have something to hide!
I have no problem with labeling, as long as we make sure we label all the GMO products, not just the ones that resulted from gene splicing. We also need to label all of the products that resulted from mutation breeding, using radiation, transposons or mutagentic chemicals to cause large numbers of random mutations. Obviously, those products are much more dangerous than the ones created by carefully altering one tiny section of the organism's DNA.
Unfortunately, there's a problem: labeling the results of mutation breeding would require labeling virtually everything in the grocery store. Mutation breeding has been widely used for a century now, and most of the strains we currently eat were produced that way. So if we labeled accurately, the labels would be uninformative.
And this is why I actually oppose labeling. If accurate labels are uninformative, then inaccurate labels can have no value whatsoever.
If you want to add a label that says something useful related to the riskiness of eating an organism, perhaps the best thing to do is to identify the age of the strain. Something we've been eating for a thousand years is likely safe (not that there's anything that old in the grocery store). Something we've been eating for 50 years is less safe, but probably safer than something that just came into existence last year, in the sense that there's a better chance we've observed the negative effects.
So, if you want to label, I'd say label by the age of the strain, whether it was created by gene splicing, mutation breeding or "natural" selective breeding (which is only different from mutation breeding in that it relies on cosmic rays and other "natural" mutagens to provide the mutations for selection). What would really be ideal is to label with an estimate of the number of people who've eaten that strain without apparent harm, perhaps weighted by how long ago they ate it, in order to increase the odds that problems would have been observed.
That would be scientifically-accurate and useful information that you could put on a label.
So Apple just has to "un-exist" it when they are done. Develop and use it in a clean room, then destroy the contents of the room once they hand over the pin to the FBI, if it turns out that the FBI has a constitutional right to demand Apples assistance.
Oh, and then re-create it for each of the next 200 phones the FBI wants into... making sure that no copies every leak, each time.
This case isn't about Farook's phone. Everyone knows there's nothing of use on it anyway... anything of value would have been on one of his burner phones, which the FBI knows he had and knows he destroyed, not on the phone that he knew was being backed up to iCloud under an employer-owned account. This is all about the precedent. The FBI picked this phone because "terrorist!", but even they don't care about this one. It's all about the rest.
For example how exactly are you supposed to direct the car to a specific parking spot inside a garage?
Yep I'm sure the best and brightest minds in car automation haven't given this a moment's thought. What idiots!
The real question is... why do you care where your network-connected self-driving car parks? Let the damned thing figure it out by itself. Whey you need it, you don't go find it, you grab your phone and tell it to come to you.
For example how exactly are you supposed to direct the car to a specific parking spot inside a garage?
Why would you want to? Just get out and let the car figure out where to park. Or maybe tell it to go home. When you're ready to go, just use your phone to tell the car where to pick you up.
I can't imagine what leads Google to think they can actually solve EVERY problem an autonomous car will run into with the very first version.
This is very, very far from the first version.
Where exactly does that extraordinary self-confidence (hubris?) come from?
Several years and ~1.5 million miles of real-world testing.
That is, designers felt the damn thing didn't look futuristic enough if it still had a steering wheel and petals.
No, actually. The people working on it have explained at length why they took this step, and it derived from actual experience and testing. There are two problems with putting controls in a self-driving car. First, it makes people think that the car can get away with self-driving most of the time and expecting the human driver to take over when something bad happens. But Google's experience with early systems, given to employees to use with strict instructions to pay attention as though they were driving and be ready to take over showed that even people who understand the risks tend to put way too much faith in the system. This means that the system must be able to handle driving entirely on its own, because as soon as it looks remotely capable, people will let it.
The second problem with having controls is that drivers may actually try to take control when they think they know better than the car... and they'll do it with less understanding and less context and no idea why the car is doing what it's doing (because they really haven't been paying attention, and anyway aren't equipped with sensors that are nearly as good as the car's), and in so doing will do the *wrong* thing. Fundamentally, it's a very bad idea to divide control between two drivers. If the car is driving, the car should drive and the people should be passengers. The best way to enforce this view on designers and passengers alike is to remove the controls.
Because I program automation system, and one thing I do know is that Executives are so fucking fickle that they can not make a decision to save their own life. No A.I. on the planet will be able to handle an Executive or CEO.
CEO:"I do not like this system there are black bars on the screen." A.I.: "you demanded we use a 16:10 projector on a 16:9 screen, you even used executive override protocol even though we told you they were incompatible and would have black bars"
CEO:" make it work without black bars" A.I.: " we will have to change the screen or the projector, what do you prefer"
CEO:" Use what I wanted, make it work" A.I.:"......... Illogical...... Murder...... Kill.... Destroy......."
Meh. Just scale it to fill. It'll be slightly stretched vertically, but not enough that most people (including the CEO) will notice.
For that matter, if the video that will be displayed is of the CEO, he may understand *exactly* what he's asking for, and the AI is just being dense. Maybe he wants the slight deformation of the video to make him look taller. Not so much that it's obvious, but enough that it may influence the perceptions of the viewers.
Soon, human beings will be the first living organism to cause self-obsolescence.
Not the first. The vast majority of species that have lived on Earth have caused self-obsolescence and died out as a result. We're just considering a different and more efficient route to this most normal of ends.
Health effects, whatever. I feel better when I can change positions every now and then. Sitting all day leaves me feeling tired and my back gets sore (yes, I've tried lots of different chairs). With a sit/stand desk I change positions every hour or two, switching between standing, sitting on a moderately-ergonomic desk chair and sitting on an exercise ball. The latter is actually fairly hard work to sustain for a long time, but I think my core has gotten stronger for doing it. Standing eventually makes my feet hurt. No one position is ideal, but changing it up seems to work great.
It might not be smart to quit if, while employed, they are under Apple's umbrella of legal protection. Alone in the wild, could employees with knowledge on how to crack the phone* be pressured to crack the phones?
If the design is any good -- and I'm quite sure it is -- then knowledge doesn't matter. What matters is possession of the Apple signing keys, and departing employees wouldn't get to take those with them.
* = "Hey, remember when Apple said phones couldn't be cracked? Ha, good times, good times. (cries in beer)"
All security is relative to a threat model, and when Apple said that they -- quite reasonably -- didn't consider Apple being ordered to sign weakened versions of their security software as part of their threat model.
You can't pick and choose which laws or warrants you obey - that way lies anarchy.
If only you were around to explain this to Rosa Parks.
I am wondering who will quit their 6-digit salary paying swanky job in the Silicon Valley, just because they do not agree with the law enforcement. Maybe 1 or 2 people with some screws loose upstairs, but no sane person would do such a thing.
Considering your integrity to be more important than your job -- even when you can easily get another just as good -- is insane. Got it.