How can any CEO keep their job after their stock value was chopped in half in less than a year?
First, it didn't get chopped in half. AAPL peaked at 702, and troughed at 390, give or take. Second, at no point did AAPL lose much more than about a year worth of gains. Every dollar the stock lost was a dollar that it also gained under Tim Cook, at approximately the same rate.
News flash: AAPL is prone to wild swings. Nothing new here. The only difference this time is that there's a whole new crop of pundits who don't remember 2008, 2001, etc.
Their state economy is not borked like California...
California's state economy is hosed in large part because of a few serious mistakes made many, many years ago.
Prop 13 is by far the worst of those mistakes. It means that the state's property tax burden is disproportionately suffered by new homeowners, and means that businesses and rental properties pay almost nothing proportionally. This discourages new construction and home buying and encourages renting, a problem that made California's housing bust much worse than it would otherwise have been.
On top of that, various other propositions have carved out specific taxes for specific purposes, limiting the legislature's ability to adapt to lean years, and limiting its ability to save money in good years.
Now that the economy is back on track, California is on track to have a budget surplus again. I'm cautiously optimistic that Governor Brown will manage to coerce the legislature into saving at least a small amount of that surplus instead of blowing it all like a meth addict.
This is the point where Paypal learns the hard way that his parents did not consent to him accepting the terms of service where he agreed to mandatory binding arbitration.
A single person (Nader) dropping out would likely have changed enough votes to matter. There's likely no single action by any single person that would have prevented those Democrats from voting for Bush.
It doesn't matter how many Democrats voted for Bush. It doesn't matter that there are multiple things that could have prevented the outcome. Every single one of those events is equally responsible for that outcome because the absence of any one of those events would have prevented that outcome. Therefore, Nader is just as much to blame as the Democrats who voted for Bush, and just as much to blame as the people who designed the ballot that caused some confused Democrats to accidentally vote for Buchanan, etc.
Nearly every Green Party vote would likely have gone to Gore had Nader not run. So no, I am not blaming those 500 people who voted for Nader. I'm blaming Nader.
A good third-party candidate should seriously assess his/her chances of winning, and when it becomes clear that a win is not possible, should drop out of the race and allow those votes to go to the lesser of two evils. Any candidate who does not do that is reckless and irresponsible.
The most responsible people (besides those republicans that were obviously going to vote for bush anyway) was the Democrats who voted for Bush, not the 3rd party people.
What Democrats who voted for Bush? Do you mean the ones who voted for Pat Buchanan because the ballot design sucked? Yes, had that unfortunate event not occurred, it would have tipped the election. Nader doesn't automatically get a pass for his poor judgment merely because there were other mistakes that contributed to the problem. Every mistake of sufficient magnitude is equally responsible, because it doesn't matter how many votes you win by as long as you win.
To use an analogy, three people are standing around and see a girl get raped by an unarmed man, but do nothing. One of the witnesses has a sword, a second has a handgun, and a third has an M16/M203. Your argument is that the one with the machine gun is most to blame for not stopping the rape because he could have inflicted the most damage to the rapist. From the victim's perspective, however, all three are equally to blame because what matters is whether enough force was used to stop the rape from happening; the amount of additional force beyond that point does not change whether the girl got raped.
You can when the margin in Florida was only a little over five hundred votes. In point of fact, had any single third-party candidate chosen not to run, and had all of that candidate's votes gone to Gore, it would have tipped the election solidly to Gore.
It's a 33% decrease in systemwide power consumption, of which the CPU is only part. So if their statement is accurate, it means that they're cutting their TDP by significantly more than 33%, per Amdahl's law.
Most things the user does require virtually no CPU.... In short, practically no typical user actually needs serious single thread performance any more — what they need is good multithreaded performance, so that their computer can do a million pointless things behind the scenes without causing their cat videos to skip.
I would go one step further and say that the majority of users need neither better single-threaded performance nor better multi-threaded performance. They just need newer hardware that isn't on its last leg.
Beyond the first two or three cores, throwing additional cores at the problem provides little benefit for basic tasks. Video decoding might be multithreaded, but it is usually not massively multithreaded. At best, most of the decoding software I've worked with uses one thread to decompress and a second thread to deinterlace, so you're unlikely to use more than two cores total, in my experience, with the exception of the tiny trickle of CPU power required to fetch the data over the network or from disk in the first place.
And good app responsiveness typically requires only two cores, give or take—one to offload the minor background tasks so that they don't get backed up too far behind the foreground processing and one to handle the foreground app's processing needs. Beyond two cores, the benefits start to fall off pretty rapidly. I can perceive very little difference in responsiveness between my current-generation MacBook Pro (4-core 2.7 GHz Core i7) and my circa 2007 black MacBook (2-core 2.16 GHz Core 2 Duo) except in CPU-hungry apps like Photoshop. Once you get past four cores or so, the only benefit is for people running massively multithreaded tasks, which isn't typical end-user stuff by any stretch of the imagination.
The big difference that faster single-core performance gets you, assuming all other things are equal, is better battery life—being able to crank through the background tasks in less time means the CPU is idle longer. So more single-threaded performance per watt is a big win over more multi-threaded performance per watt because the former is more likely to result in power savings.
Choice 3. The government declares that research use of the intellectual property is in the public's best interest, confiscates the patent through eminent domain, and invalidates it.
Screen is sucking up most battery power in the system (by a wide margin).
Maybe with the old fluorescent backlights, but not these days. A typical LED backlight on a laptop draws something like 3 watts at maximum brightness. It isn't lost in the noise, but it is by no means the main power draw. The CPU, chipset, and RAM take way more current.
That's true. However, given that an earlier part of the post indicated that he/she spent 85% of his/her waking time in the office, it is clear that flexible time is not what was meant. That's approximately a 95-hour workweek. Even if you interpret it as 85% of your waking life during the five days that most people work, that's still a 68-hour workweek. Neither one is healthy, even for short periods of time, much less on an ongoing basis. A 40-hour workweek is about 36 percent of your waking life, and for jobs that involve serious thinking, studies have shown that even that is well above the point of diminishing returns.
Now lets be clear that I'm not talking about a FPGA! In a FPGA if you "reload" the software you will change the machine because in essence the "software" for a FPGA is like the internal gear system, you can configure it in 1000 different ways to do different tasks. One day it can be a conveyor build and the next it will be a bottle cap remover. So before someone comes in here and blows a gasket at me, I fully accept the fact that a FPGA is very different then a Computer.
Ah, but an FPGA can be simulated in software. Therefore, if you reload the software in the simulator, you change the virtual machine. How is the fact that one is emulated and the other is physical relevant?
The way I look at it, software certainly adds a new state machine into the picture. Whether that qualifies as a machine for patent purposes is a separate question, and there are legitimate arguments on both sides, but whichever way you decide, an FPGA should play by the same rules as software.
Thanks for the explanation. My memory of the actual math involved was a little bit off.
Either way, though, the point remains that if the token is in software and the host is compromised, an attacker can obtain the current value of the key and can generate a new number transparently at any time, and it won't be detectable so long as the attacker updates the button press count on compromised device so that the server doesn't see the same button press count twice with different time stamps.
And cookies. But yes, you're right that they don't necessarily have to wait for the user to log in to Google unless that's the only site they care about and the user has not yet logged in to that site. (And apologies for my bad grammar for saying "log into" as well.)
If that were the case, then a single failed login (because of network congestion, for example) would prevent you from ever logging in again. Nobody destroys the shared key. They prevent using passwords twice by using an authentication server that marks the last successful login time and won't let you use a time-based authentication token generated on or before that time stamp (or some similar technique).
The way time-based auth usually works is that either the shared key is hashed with some sort of time stamp or the shared key is used as one of the inputs to a PRNG function whose other input is the number of 30 second periods since some arbitrary time in the past. Given the same key and the same time, the two endpoints can generate the same pair of values, and the authentication server can compare the received value with the expected value. In the latter case, it also typically compute one period before and one period after the current one, to allow for clock drift.
CryptoCard devices do the same basic thing, as I understand it, but the second input is the number of times the button has been pressed. On the server side, it computes the next n possible values after the last one successfully used (where IIRC n is configurable by the server administrator) and if any of them match, that becomes the last one successfully used going forward.
Either way, once that key is compromised (or in the case of CryptoCard, the key plus the number of times you've pushed the button), the system breaks down. This is why your IT department won't give you a copy of the private key associated with your dongle....:-)
Here's how I know you don't know what you're talking about: All of the things I've talked about have happened already.
Really? Really? Just like that, compromises my cell phone, which is never out of my possession?
A smartphone? You bet. There have been at least two jailbreaks (read "root compromises) for iOS that were triggered by simply going to a web page. In those particular cases, the user knew that he/she was going to a website that did this, but it could just as easily be done surreptitiously.
Nobody bothers to root Android that way because there are generally easier ways to do it, but that doesn't mean it is impossible or even more difficult than it was for iOS. Nor is there any reason to believe that identity thieves do not already have such techniques in their arsenal.
And waits for the user to log into google
Again, Really? Do you even have a clue how Google authenticator works?
You don't log into google with the authenticator. You log in with some other computer over a ssl connection.
First, that's not necessarily true. Most users do use their phones as browsers, too, which means the device is often the same piece of physical hardware.
Second, even when you do have a proper physical separation between the authenticator and the browser, the only thing it changes is which attacks are relevant:
If the computer is the compromised device, attacks 1, 2, and 3 are possible.
If the mobile phone is the compromised device, attack 4 is possible.
In short, the separation is mostly a security no-op.
Even if you had a pre-compromised computer and an elaborate SSL spoofing setup in place ahead of time
Once the endpoint of an SSL/TLS link is compromised, you don't need any spoofing. You can drop an extra self-signed anchor cert into the appropriate trusted anchors list, and you're trusted. There's nothing elaborate about it. It's downright trivial. I can throw together a proof of concept in about three minutes.
For that matter, once the endpoint is compromised, you can just tweak it to display the little lock icon while sending data in the clear. SSL and TLS are worthless if the endpoint is compromised. Completely worthless.
But wait, that wouldn't work either because
google already detects this.
Correction. Chrome detects this, but only if the user is running Chrome and that copy has not been modified by the attacker. Once the computer is compromised, you cannot rely on that, either. Any attacker capable of compromising the computer is also capable of compiling a copy of Chrome with those checks disabled. Besides, even if those checks could magically be made impossible to remove, they would still only effectively guard against attack #2, which still means the security hole is wide enough to drive an Abrams tank through it.
It is not possible to detect a man-in-the-middle attack where one of the endpoints is compromised. Period. You're trying to argue against one of the most fundamental tenets of computer security here. There is exactly one way to guarantee that a transaction is secure, and that requires either cryptographic signing or some other form of cryptographic authentication between two trusted endpoints.
Assuming the servers are secure (which isn't 100% certain, but it's sort of an unavoidable assumption), the remaining piece is a hardware device that is not field programmable, that has a screen to show information about a transaction, buttons to authorize or cancel that transaction, and a simple communication protocol, with code that has been proven to be bug free using formal verification techniques. Anything less than that is at best only trivially more secure than passwords.
Slashdot Mirror
First, it didn't get chopped in half. AAPL peaked at 702, and troughed at 390, give or take. Second, at no point did AAPL lose much more than about a year worth of gains. Every dollar the stock lost was a dollar that it also gained under Tim Cook, at approximately the same rate.
News flash: AAPL is prone to wild swings. Nothing new here. The only difference this time is that there's a whole new crop of pundits who don't remember 2008, 2001, etc.
California's state economy is hosed in large part because of a few serious mistakes made many, many years ago.
Prop 13 is by far the worst of those mistakes. It means that the state's property tax burden is disproportionately suffered by new homeowners, and means that businesses and rental properties pay almost nothing proportionally. This discourages new construction and home buying and encourages renting, a problem that made California's housing bust much worse than it would otherwise have been.
On top of that, various other propositions have carved out specific taxes for specific purposes, limiting the legislature's ability to adapt to lean years, and limiting its ability to save money in good years.
Now that the economy is back on track, California is on track to have a budget surplus again. I'm cautiously optimistic that Governor Brown will manage to coerce the legislature into saving at least a small amount of that surplus instead of blowing it all like a meth addict.
Yes, yes it is. No, no it will not be. TPTB like it that way.
This is the point where Paypal learns the hard way that his parents did not consent to him accepting the terms of service where he agreed to mandatory binding arbitration.
A single person (Nader) dropping out would likely have changed enough votes to matter. There's likely no single action by any single person that would have prevented those Democrats from voting for Bush.
It doesn't matter how many Democrats voted for Bush. It doesn't matter that there are multiple things that could have prevented the outcome. Every single one of those events is equally responsible for that outcome because the absence of any one of those events would have prevented that outcome. Therefore, Nader is just as much to blame as the Democrats who voted for Bush, and just as much to blame as the people who designed the ballot that caused some confused Democrats to accidentally vote for Buchanan, etc.
I think Eric Schmidt was hoping that his earlier comment about privacy would go away... but, being on the Internet, it never will.
Nearly every Green Party vote would likely have gone to Gore had Nader not run. So no, I am not blaming those 500 people who voted for Nader. I'm blaming Nader.
A good third-party candidate should seriously assess his/her chances of winning, and when it becomes clear that a win is not possible, should drop out of the race and allow those votes to go to the lesser of two evils. Any candidate who does not do that is reckless and irresponsible.
What Democrats who voted for Bush? Do you mean the ones who voted for Pat Buchanan because the ballot design sucked? Yes, had that unfortunate event not occurred, it would have tipped the election. Nader doesn't automatically get a pass for his poor judgment merely because there were other mistakes that contributed to the problem. Every mistake of sufficient magnitude is equally responsible, because it doesn't matter how many votes you win by as long as you win.
To use an analogy, three people are standing around and see a girl get raped by an unarmed man, but do nothing. One of the witnesses has a sword, a second has a handgun, and a third has an M16/M203. Your argument is that the one with the machine gun is most to blame for not stopping the rape because he could have inflicted the most damage to the rapist. From the victim's perspective, however, all three are equally to blame because what matters is whether enough force was used to stop the rape from happening; the amount of additional force beyond that point does not change whether the girl got raped.
You can when the margin in Florida was only a little over five hundred votes. In point of fact, had any single third-party candidate chosen not to run, and had all of that candidate's votes gone to Gore, it would have tipped the election solidly to Gore.
You wouldn't steal a keyboard? Would you steal a handbag? A DVD?
Oops. Sorry. Wrong thread.
It's a 33% decrease in systemwide power consumption, of which the CPU is only part. So if their statement is accurate, it means that they're cutting their TDP by significantly more than 33%, per Amdahl's law.
I would go one step further and say that the majority of users need neither better single-threaded performance nor better multi-threaded performance. They just need newer hardware that isn't on its last leg.
Beyond the first two or three cores, throwing additional cores at the problem provides little benefit for basic tasks. Video decoding might be multithreaded, but it is usually not massively multithreaded. At best, most of the decoding software I've worked with uses one thread to decompress and a second thread to deinterlace, so you're unlikely to use more than two cores total, in my experience, with the exception of the tiny trickle of CPU power required to fetch the data over the network or from disk in the first place.
And good app responsiveness typically requires only two cores, give or take—one to offload the minor background tasks so that they don't get backed up too far behind the foreground processing and one to handle the foreground app's processing needs. Beyond two cores, the benefits start to fall off pretty rapidly. I can perceive very little difference in responsiveness between my current-generation MacBook Pro (4-core 2.7 GHz Core i7) and my circa 2007 black MacBook (2-core 2.16 GHz Core 2 Duo) except in CPU-hungry apps like Photoshop. Once you get past four cores or so, the only benefit is for people running massively multithreaded tasks, which isn't typical end-user stuff by any stretch of the imagination.
The big difference that faster single-core performance gets you, assuming all other things are equal, is better battery life—being able to crank through the background tasks in less time means the CPU is idle longer. So more single-threaded performance per watt is a big win over more multi-threaded performance per watt because the former is more likely to result in power savings.
Considering that everything is ultimately running off a battery that provides only a single voltage, the distinction is moot.
Choice 3. The government declares that research use of the intellectual property is in the public's best interest, confiscates the patent through eminent domain, and invalidates it.
Maybe with the old fluorescent backlights, but not these days. A typical LED backlight on a laptop draws something like 3 watts at maximum brightness. It isn't lost in the noise, but it is by no means the main power draw. The CPU, chipset, and RAM take way more current.
Much less someone who claims to be against eminent domain.
I'm pretty sure we already know the answer. The cat is dead. Curiosity killed it.
That's true. However, given that an earlier part of the post indicated that he/she spent 85% of his/her waking time in the office, it is clear that flexible time is not what was meant. That's approximately a 95-hour workweek. Even if you interpret it as 85% of your waking life during the five days that most people work, that's still a 68-hour workweek. Neither one is healthy, even for short periods of time, much less on an ongoing basis. A 40-hour workweek is about 36 percent of your waking life, and for jobs that involve serious thinking, studies have shown that even that is well above the point of diminishing returns.
I wouldn't. I'd rather not be there at 8 o'clock at night. This is a sure sign of poor management.
Ah, but an FPGA can be simulated in software. Therefore, if you reload the software in the simulator, you change the virtual machine. How is the fact that one is emulated and the other is physical relevant?
The way I look at it, software certainly adds a new state machine into the picture. Whether that qualifies as a machine for patent purposes is a separate question, and there are legitimate arguments on both sides, but whichever way you decide, an FPGA should play by the same rules as software.
Thanks for the explanation. My memory of the actual math involved was a little bit off.
Either way, though, the point remains that if the token is in software and the host is compromised, an attacker can obtain the current value of the key and can generate a new number transparently at any time, and it won't be detectable so long as the attacker updates the button press count on compromised device so that the server doesn't see the same button press count twice with different time stamps.
And cookies. But yes, you're right that they don't necessarily have to wait for the user to log in to Google unless that's the only site they care about and the user has not yet logged in to that site. (And apologies for my bad grammar for saying "log into" as well.)
If that were the case, then a single failed login (because of network congestion, for example) would prevent you from ever logging in again. Nobody destroys the shared key. They prevent using passwords twice by using an authentication server that marks the last successful login time and won't let you use a time-based authentication token generated on or before that time stamp (or some similar technique).
The way time-based auth usually works is that either the shared key is hashed with some sort of time stamp or the shared key is used as one of the inputs to a PRNG function whose other input is the number of 30 second periods since some arbitrary time in the past. Given the same key and the same time, the two endpoints can generate the same pair of values, and the authentication server can compare the received value with the expected value. In the latter case, it also typically compute one period before and one period after the current one, to allow for clock drift.
CryptoCard devices do the same basic thing, as I understand it, but the second input is the number of times the button has been pressed. On the server side, it computes the next n possible values after the last one successfully used (where IIRC n is configurable by the server administrator) and if any of them match, that becomes the last one successfully used going forward.
Either way, once that key is compromised (or in the case of CryptoCard, the key plus the number of times you've pushed the button), the system breaks down. This is why your IT department won't give you a copy of the private key associated with your dongle.... :-)
Here's how I know you don't know what you're talking about: All of the things I've talked about have happened already.
A smartphone? You bet. There have been at least two jailbreaks (read "root compromises) for iOS that were triggered by simply going to a web page. In those particular cases, the user knew that he/she was going to a website that did this, but it could just as easily be done surreptitiously.
Nobody bothers to root Android that way because there are generally easier ways to do it, but that doesn't mean it is impossible or even more difficult than it was for iOS. Nor is there any reason to believe that identity thieves do not already have such techniques in their arsenal.
First, that's not necessarily true. Most users do use their phones as browsers, too, which means the device is often the same piece of physical hardware.
Second, even when you do have a proper physical separation between the authenticator and the browser, the only thing it changes is which attacks are relevant:
In short, the separation is mostly a security no-op.
Once the endpoint of an SSL/TLS link is compromised, you don't need any spoofing. You can drop an extra self-signed anchor cert into the appropriate trusted anchors list, and you're trusted. There's nothing elaborate about it. It's downright trivial. I can throw together a proof of concept in about three minutes.
For that matter, once the endpoint is compromised, you can just tweak it to display the little lock icon while sending data in the clear. SSL and TLS are worthless if the endpoint is compromised. Completely worthless.
Correction. Chrome detects this, but only if the user is running Chrome and that copy has not been modified by the attacker. Once the computer is compromised, you cannot rely on that, either. Any attacker capable of compromising the computer is also capable of compiling a copy of Chrome with those checks disabled. Besides, even if those checks could magically be made impossible to remove, they would still only effectively guard against attack #2, which still means the security hole is wide enough to drive an Abrams tank through it.
It is not possible to detect a man-in-the-middle attack where one of the endpoints is compromised. Period. You're trying to argue against one of the most fundamental tenets of computer security here. There is exactly one way to guarantee that a transaction is secure, and that requires either cryptographic signing or some other form of cryptographic authentication between two trusted endpoints.
Assuming the servers are secure (which isn't 100% certain, but it's sort of an unavoidable assumption), the remaining piece is a hardware device that is not field programmable, that has a screen to show information about a transaction, buttons to authorize or cancel that transaction, and a simple communication protocol, with code that has been proven to be bug free using formal verification techniques. Anything less than that is at best only trivially more secure than passwords.
You owe me a new keyboard.