All forms of authentication rely on the two parties, and only the two parties, knowing a piece of information.
There is no getting around that. Public key encryption does not. Whatever wikipedia link you provide does not.
There seems to be some confusion here on what I was claiming. At some point the server needs to know some piece of information to use to positively identify the client. If this is a password, then the server has to know that the password it gets in the first place is really the one the client wanted to set. I agree that this is a hard problem with no clear solution, although SSL/TLS seems to do a pretty good job of it.
I was also discussing the problem that the server should not be able to log into another server as the client using that information. The most well-known example is probably SSH's public key login scheme where the server knows only the public key and the client knows the private key and never needs to reveal any of the private key to the server in order to log in. Similarly, a server can know only a hash of a client's password (concatenated with a salt and possibly some other info) and the client can prove it knows the password without actually telling the password to the server (for example, by the method used in HTTP digest auth of concatenating the password hash with some challenge and then hashing it again, note that the server can login to another server that has the exact same password hash in that case, but in a properly setup system, that never happens).
No, the user may authenticate locally (that is, within a trusted system) with a password, but a password should never be sent over the internet, even encrypted (maybe hashed with a challenge, but not just encrypted). You use public key encryption or even a zero-knowledge proof. There does need to be a secret that the client uses to authenticate itself, but transmitting the secret, even encrypted, is a horrible idea for security as it completely falls apart as soon as there is even the slightly flaw in the encryption or server authentication.
Having the server know the password at all is a bad idea, too (bad things happen when the user uses the same password for multiple services), but it is a bit harder to avoid as, in general, the user needs a way to log in from any computer and having a file or dongle required is bad (one solution is to use a hash of the user-entered password and the domain as the password, which is basically what digest auth does).
The poor security here is mostly on the user's side, making it difficult for the bank to be sure they are really connected to their customer, so I am not sure how making security the bank's responsibility will change that. I guess distributing live CDs and requiring users to use them when banking would one way to enforce good security on user's computers (while banking). Obviously it is not reasonable to expect to be able to tell what software a remote user is running, but just user agent checking or having the live CD's browser have a client-side certificate which the bank's login page checks for would discourage most users from not using the live CD.
Good point. Hopefully anyone designing such a device does not hire me as their usability expert.;-)
Seriously, you may or may not be able to create a device such that the user cannot be tricked like that. For example, have "transfer" and "login" buttons on the device and have login keys always start with "login". This may or may not be clear enough.
None of this will work with the problems described in the article, if someone has control of your computer then you're screwed no matter what kind of authentication you have.
That's not entirely true. If there is some sort of challenge-response scheme that involves the "what you have" part of the authentication (either by a lookup in a table of single-use tokens or by typing the challenge into a security token-like device) and the challenge is based on what the user is requesting to do (ex. the user explicitly types the amount and target account number into their security token and then feeds the response into the website), then you can avoid unauthorized transfers even from a compromised computer.
Of course, it would be best if computers weren't compromised, and booting an OS off a CD is good way to be relatively sure of that, but, realistically, most bank customers are going to be using computers with some amount of malware on them for the foreseeable future.
Wonderful idea. But it has very little to do with this attack. RSA keyfobs ensure that if you log on now, an observer cannot log on to your account at some later time, which is a good thing to guarantee. Note that the generated PIN may be unique, but the attacker can get around that by simply sharing a session with you. This requires the attack to be real-time, so it does make it somewhat more difficult.
If the attacker controls your computer, then I cannot see how you could still prevent an attacker from making transactions without having a challenge-response based on the transaction performed by something not directly connected to the computer (a physical page of single-use codes would work and some people on/. have mentioned their bank using such a solution).
Trying to use a possibly rooted computer to do something securely is a hard problem, but unfortunately it is one that has to be dealt with. Optimally, people would be using more secure setups, but that is not realistic, especially when successful exploits can net such large sums of money.
That should definitely raise a red flag at a bank. Credit card companies definitely do that type of check. On the other hand, if your computer is already infected with malware, making the attacker proxy the connection through your computer (and use the same cookies and user agent, too, so it looks like the same user) seems like a minor hoop to jump through.
I agree that suing the banks seems like a strange reaction, but this type of attack only works because the banks simply do not care about security. On previous articles I have seen posters mention their banks (somewhere in Europe) have papers which have a list of single-use transaction codes which are used in some sort of challenge-response system. For example, choosing a code based on the transaction date, target, amount, and some randomness would protect against attacks like the one described where a compromised computer is used to drain a bank account.
The client should have better security -- after all, even seeing the bank account info would likely be interesting to some attackers -- but the banks need to be held accountable for their lack of security features as well.
As the sibling mentioned, other sites have mentioned that it does, which makes sense. I thought Nokia might be being silly and only supporting Bluetooth headsets.
The article mentions TV-out and shows a screenshot of a configuration screen for it (with the TV-out in PAL mode). On the other hand, it is not clear what kind of sound output the device has. The article seems to say that the TV-out plug and a micro-USB plug are the only ports on the device, so that would mean no headphones/headset jack, so I am not sure how you would get sound to a TV for watching movies off of it. I guess it is still useful for displaying photos and presentations anyway.
It sorta feels like cheating in this context, though: "Hey, why are you wasting your time going to 2.5 trillion digits? I calculated pi exactly, it's '10'... in base pi.".;-)
Yes, talking about base-n "decimal" expansions sounds a bit silly. I guess you could say "representation in base-n", but usually I would be mentioning decimal expansions to emphasize that I am talking about the possibly infinite part of a real number. Maybe "base-n expansion" would be a bit clearer...
For normal usage, yes, but for specialized uses like calculating pi or just dealing with big numbers in general or numbers where it is important that the rounding be done in decimal (ex. financial information) there are libraries that handle math on numbers stored as decimals (probably using some sort of compressed format like BCD or DPD for big numbers, sometimes just using strings for small numbers like older versions of MySQL). Using decimal is going to be slower and more complicated than using binary on a computer, which is why it is not usually done.
Symbolic algebra systems tend to support storing rationals as rationals. See: a TI-89, Maxima, Mathematica, etc.
Anyway, my point was that a computer is only going to be able to store a terminating decimal of some length exactly, so calling only those numbers "computable" seems rather counter-intuitive, especially since which numbers have terminating decimals is dependent on the chosen base.
Actually, the program itself is a perfectly fine way of representing pi. See: computable numbers. Note that almost all real numbers are not computable, so it is a non-trivial property.
Require the "weather forecasting" app to submit an approval to a central repository like the iPhone.
See where I am leading you...
Yes, and it is a bad idea. Secure the OS by securing the OS, not by adding in a random trusted third-party that will probably make mistakes anyway (maybe we should call that "security by authority"?). Sandbox applications so they only have access to the files and services they need, perhaps with permissions like "safe" network access which is capped or can only access one server or port or has to display the bandwidth used on screen and be advertized as a possibly dangerous high-network usage application (ex. for a p2p app). Google's Android has a per-application permissions system where users are told which permissions an application is requesting on install. App Armor allows for simple sandboxing on Linux. IE8's sandbox is a definite good step in the right direction.
With App Armor there have been suggestions of "generic profiles" like web browser, game, p2p program, etc. which would have less strict limitations than a program-specific profile but still limit what the application can do while presenting the limitations in a way the user can understand.
One way to handle anything like network access limitations I mentioned above might be to create a separate virtual network adapter for every application.
Let legacy applications live in virtualized environments if necessary. There is no reason to not let an application run just because it is old, although paying some amount of emulation penalty is reasonable and unlikely to be an issue.
The inability to run any common Windows software, even with WINE (or Mono), is also likely to be a problem.
One of the major advantages of a managed code language like C# or Java is that it is compiled for the VM which can be ported to any platform. Running native Windows applications would require an emulator, which would probably not be very fast but the software does exist. A.NET or Java application should run on ARM without modification as long as it does not use closed-source native libraries. Of course, the JIT compiler needs to be platform-specific, and I am not sure how much Mono focuses on their ARM port. LLVM and other portable intermediate bytecode projects may help there.
A secondary system running the same code with the same flaws as the first doesn't cut it in this context.
That's why you build the computer systems with triple modular redundancy. Basically, you make three different systems which have the same job and they vote.
Of course, a human or two as another layer of redundancy is often a good idea.
IMHO the GPL, even v3, needs some work to clarify this question and also to close the hole for the software-as-a-service industry to modify GPL code without reciprocating.
I think the Affero General Public License is the answer to your second point. Although I suspect that Affero-like terms were very intentionally left out of the GPL as running applications remotely is not at all a new concept.
I mostly agree with you (err... see my signature), but I am not sure why your examples are actually problems. I find "cloud computing" more of an issue for services like GMail or Google Docs where private information is getting stored unencrypted with a third party. I do not think the fix is to kill "cloud computing", but to develop services that are (1) open source so they can be deployed internal to an organization or (2) encrypted server-side so there is no breach of privacy (or both). Some peer-to-peer distributed encrypted storage would be cool, but I don't think the part where the service runs on a specific web server is necessarily a problem.
I find it a bit silly that Twitter and Facebook are centralized, and I avoid using Facebook messages (if Facebook wants to read my e-mail, they can sniff the packets; they're probably sent in the clear anyway), but I am not sure what the privacy concerns are with those services being centralized. They are both mainly for posting more or less public information. I would consider actual friends lists private information, but pretty much everyone I know has pretty much everyone they have ever met who has a Facebook on their friends list (possibly along a few they have never met), so that information is sufficiently dilute to be nearly worthless.
we open ourselves to identity theft on a scale unimagined.
If you can get credit in a person's name using the information in their Facebook profile, then the problem lies with identify verification system. The fact that the information is more accessible now just makes the problem more visible.
There have been very small quantum computers demonstrated. IBM made a 7-qubit one and ran Shor's algorithm (for polynomial-time factoring) on it in 2001. As far as I can tell, that is the highest number of qubits anyone has demonstrated in a quantum computer.
The main evolutionary reaction to incest is the Westermarck effect, which basically means that people usually are not sexually attracted to anyone they spent a significant amount of time around during the first six years of their life. As that usually includes their parents and siblings, it greatly discourages incest.
There are other posts on this thread suggesting that teenage rebellion only occurs in some cultures, so biological evolution does not explain it, although you could perhaps argue that cultural evolution does... but I am not really sure how that would work.
Hmmm... I agree that the assumption that the brain's working are "mechanical" is non-trivial, but I am not aware of any reason to believe it is false. You seem to be stating that it is an undisputed fact that the brain's workings are not "mechanical". Why? Do you have a source for this?
Here, let me clarify it for you. I hereby 'declare' as a key assumption that the Heisenberg Uncertinty principle is an important part of how nuerons work.
Okay, you just made the simulation much, much more computationally expensive. But not impossible.
Folding@home and other computational biology projects assume that various biological processes can be correctly simulated by a computer (and they can verify those results by looking at experimental data. To suggest that is not the case for the brain would require further proof.
In fact, the best way I can think of to test if the brain can be simulation is to build what should be a simulation of a brain if it can be and see if it acts anything like a real brain. It seems like simulating the brain of an animal with fewer brain cells (ex. a fruit fly) would be a reasonable simplified experiment, although it would be reasonable to argue that fruit fly brains work a lot differently than human brains so successfully simulating a fruit fly would not necessarily mean you could successfully simulate a human (although it would probably still give useful information about brains in general).
The basic problem with all the 'we can copy the brain' ideas is the basic assumption that 'it is a purely mechanical process'. That is kind of like saying "If we assume a box is made of wood, then we can build one out of a tree." No duh sherlock, but the basic thing we are arguing about is the thing you rather arrogantly assumped was true.
I did not mean to make such a trivial statement. I was giving an explanation of why what you said originally does not immediately make simulating a brain impossible: we can simulate something we don't understand. One of the goals of simulating the brain / parts of the brain is to attempt to understand it better. For example, with a real brain, using an MRI machine, one can get moderately good images of what the brain is doing, but no where near perfect. If the neurons are simulated, then finding the state of a neuron at any point in a (repeatable) simulation is trivial.
What the poster/article discusses is not in anyway close to being a worthwhile simulation of the brain in the way they imply.
Yes, we are probably at least 10-20 years away from the processing power to simulate every neuron in a human brain at a reasonable speed.
See: the Church-Turing thesis. Basically, a sufficiently powerful computer can emulate anything. Along with some simple assumptions about the nature of the physics which apply to the human body, that includes fully simulating a human brain.
On the other hand, the fact that the human brain's computations are analog instead of digital makes using normal CPUs for emulating brain cells very inefficient, hence the project mentioned in the summary to build specialized hardware for the purpose.
Not understanding the brain at all levels does not make it impossible to simulate. See: Emergence. Simulating the brain comes down to choosing a level to build the simulation at and collecting enough information about the structure of the brain at that level to actually run the simulation. Choosing the level of atoms/molecules would be far too computationally expensive (and quite difficult to collect data for), so instead the scientists are using the level of neurons, which there are various ways to get limited information about -- including running small simulations and seeing if the results match a similar lab test. On the other hand, trying simulate entire sections of the brain at once (instead of building such a simulation out of simulated neurons) is beyond our understanding of the brain.
That is, the details of how much CPU are used by the IO system aren't written to the process header, because the process header isn't in the computable scope (an area defined by a set of active register values). Ergo, "top" doesn't report that CPU because it isn't there.
You can get some idea of that usage by looking at the "Cpu(s):" line in top. Specifically, "sy"=system (kernel) time and wa and hi are related to time dealing with hardware. See man top for more details. That information is not separated out by process, but you will be able to tell the difference between a program at 30% CPU usage because it is just not doing much and a program at 30% CPU usage because the processor is busy with other tasks (possibly the I/O for that process).
I recommend using htop as it gives a visual with all of the different types of CPU usage in different colors so you can get the information at a glance (and it can separate it by CPU/core).
Slashdot Mirror
All forms of authentication rely on the two parties, and only the two parties, knowing a piece of information. There is no getting around that. Public key encryption does not. Whatever wikipedia link you provide does not.
There seems to be some confusion here on what I was claiming. At some point the server needs to know some piece of information to use to positively identify the client. If this is a password, then the server has to know that the password it gets in the first place is really the one the client wanted to set. I agree that this is a hard problem with no clear solution, although SSL/TLS seems to do a pretty good job of it.
I was also discussing the problem that the server should not be able to log into another server as the client using that information. The most well-known example is probably SSH's public key login scheme where the server knows only the public key and the client knows the private key and never needs to reveal any of the private key to the server in order to log in. Similarly, a server can know only a hash of a client's password (concatenated with a salt and possibly some other info) and the client can prove it knows the password without actually telling the password to the server (for example, by the method used in HTTP digest auth of concatenating the password hash with some challenge and then hashing it again, note that the server can login to another server that has the exact same password hash in that case, but in a properly setup system, that never happens).
No, the user may authenticate locally (that is, within a trusted system) with a password, but a password should never be sent over the internet, even encrypted (maybe hashed with a challenge, but not just encrypted). You use public key encryption or even a zero-knowledge proof. There does need to be a secret that the client uses to authenticate itself, but transmitting the secret, even encrypted, is a horrible idea for security as it completely falls apart as soon as there is even the slightly flaw in the encryption or server authentication.
Having the server know the password at all is a bad idea, too (bad things happen when the user uses the same password for multiple services), but it is a bit harder to avoid as, in general, the user needs a way to log in from any computer and having a file or dongle required is bad (one solution is to use a hash of the user-entered password and the domain as the password, which is basically what digest auth does).
The poor security here is mostly on the user's side, making it difficult for the bank to be sure they are really connected to their customer, so I am not sure how making security the bank's responsibility will change that. I guess distributing live CDs and requiring users to use them when banking would one way to enforce good security on user's computers (while banking). Obviously it is not reasonable to expect to be able to tell what software a remote user is running, but just user agent checking or having the live CD's browser have a client-side certificate which the bank's login page checks for would discourage most users from not using the live CD.
Good point. Hopefully anyone designing such a device does not hire me as their usability expert. ;-)
Seriously, you may or may not be able to create a device such that the user cannot be tricked like that. For example, have "transfer" and "login" buttons on the device and have login keys always start with "login". This may or may not be clear enough.
None of this will work with the problems described in the article, if someone has control of your computer then you're screwed no matter what kind of authentication you have.
That's not entirely true. If there is some sort of challenge-response scheme that involves the "what you have" part of the authentication (either by a lookup in a table of single-use tokens or by typing the challenge into a security token-like device) and the challenge is based on what the user is requesting to do (ex. the user explicitly types the amount and target account number into their security token and then feeds the response into the website), then you can avoid unauthorized transfers even from a compromised computer.
Of course, it would be best if computers weren't compromised, and booting an OS off a CD is good way to be relatively sure of that, but, realistically, most bank customers are going to be using computers with some amount of malware on them for the foreseeable future.
Wonderful idea. But it has very little to do with this attack. RSA keyfobs ensure that if you log on now, an observer cannot log on to your account at some later time, which is a good thing to guarantee. Note that the generated PIN may be unique, but the attacker can get around that by simply sharing a session with you. This requires the attack to be real-time, so it does make it somewhat more difficult.
If the attacker controls your computer, then I cannot see how you could still prevent an attacker from making transactions without having a challenge-response based on the transaction performed by something not directly connected to the computer (a physical page of single-use codes would work and some people on /. have mentioned their bank using such a solution).
Trying to use a possibly rooted computer to do something securely is a hard problem, but unfortunately it is one that has to be dealt with. Optimally, people would be using more secure setups, but that is not realistic, especially when successful exploits can net such large sums of money.
That should definitely raise a red flag at a bank. Credit card companies definitely do that type of check. On the other hand, if your computer is already infected with malware, making the attacker proxy the connection through your computer (and use the same cookies and user agent, too, so it looks like the same user) seems like a minor hoop to jump through.
I agree that suing the banks seems like a strange reaction, but this type of attack only works because the banks simply do not care about security. On previous articles I have seen posters mention their banks (somewhere in Europe) have papers which have a list of single-use transaction codes which are used in some sort of challenge-response system. For example, choosing a code based on the transaction date, target, amount, and some randomness would protect against attacks like the one described where a compromised computer is used to drain a bank account.
The client should have better security -- after all, even seeing the bank account info would likely be interesting to some attackers -- but the banks need to be held accountable for their lack of security features as well.
As the sibling mentioned, other sites have mentioned that it does, which makes sense. I thought Nokia might be being silly and only supporting Bluetooth headsets.
The article mentions TV-out and shows a screenshot of a configuration screen for it (with the TV-out in PAL mode). On the other hand, it is not clear what kind of sound output the device has. The article seems to say that the TV-out plug and a micro-USB plug are the only ports on the device, so that would mean no headphones/headset jack, so I am not sure how you would get sound to a TV for watching movies off of it. I guess it is still useful for displaying photos and presentations anyway.
Of course, I forgot about that.
It sorta feels like cheating in this context, though: "Hey, why are you wasting your time going to 2.5 trillion digits? I calculated pi exactly, it's '10'... in base pi.". ;-)
Yes, talking about base-n "decimal" expansions sounds a bit silly. I guess you could say "representation in base-n", but usually I would be mentioning decimal expansions to emphasize that I am talking about the possibly infinite part of a real number. Maybe "base-n expansion" would be a bit clearer...
For normal usage, yes, but for specialized uses like calculating pi or just dealing with big numbers in general or numbers where it is important that the rounding be done in decimal (ex. financial information) there are libraries that handle math on numbers stored as decimals (probably using some sort of compressed format like BCD or DPD for big numbers, sometimes just using strings for small numbers like older versions of MySQL). Using decimal is going to be slower and more complicated than using binary on a computer, which is why it is not usually done.
Symbolic algebra systems tend to support storing rationals as rationals. See: a TI-89, Maxima, Mathematica, etc.
Anyway, my point was that a computer is only going to be able to store a terminating decimal of some length exactly, so calling only those numbers "computable" seems rather counter-intuitive, especially since which numbers have terminating decimals is dependent on the chosen base.
Actually, the program itself is a perfectly fine way of representing pi. See: computable numbers. Note that almost all real numbers are not computable, so it is a non-trivial property.
It also takes an infinite amount of time to write out the decimal expansion of 1/9, but that can be written very concisely as a rational number. Also note that pi is irrational so its decimal expansion is infinite in all bases.
Require the "weather forecasting" app to submit an approval to a central repository like the iPhone.
See where I am leading you...
Yes, and it is a bad idea. Secure the OS by securing the OS, not by adding in a random trusted third-party that will probably make mistakes anyway (maybe we should call that "security by authority"?). Sandbox applications so they only have access to the files and services they need, perhaps with permissions like "safe" network access which is capped or can only access one server or port or has to display the bandwidth used on screen and be advertized as a possibly dangerous high-network usage application (ex. for a p2p app). Google's Android has a per-application permissions system where users are told which permissions an application is requesting on install. App Armor allows for simple sandboxing on Linux. IE8's sandbox is a definite good step in the right direction.
With App Armor there have been suggestions of "generic profiles" like web browser, game, p2p program, etc. which would have less strict limitations than a program-specific profile but still limit what the application can do while presenting the limitations in a way the user can understand.
One way to handle anything like network access limitations I mentioned above might be to create a separate virtual network adapter for every application.
Let legacy applications live in virtualized environments if necessary. There is no reason to not let an application run just because it is old, although paying some amount of emulation penalty is reasonable and unlikely to be an issue.
The inability to run any common Windows software, even with WINE (or Mono), is also likely to be a problem.
One of the major advantages of a managed code language like C# or Java is that it is compiled for the VM which can be ported to any platform. Running native Windows applications would require an emulator, which would probably not be very fast but the software does exist. A .NET or Java application should run on ARM without modification as long as it does not use closed-source native libraries. Of course, the JIT compiler needs to be platform-specific, and I am not sure how much Mono focuses on their ARM port. LLVM and other portable intermediate bytecode projects may help there.
A secondary system running the same code with the same flaws as the first doesn't cut it in this context.
That's why you build the computer systems with triple modular redundancy. Basically, you make three different systems which have the same job and they vote.
Of course, a human or two as another layer of redundancy is often a good idea.
IMHO the GPL, even v3, needs some work to clarify this question and also to close the hole for the software-as-a-service industry to modify GPL code without reciprocating.
I think the Affero General Public License is the answer to your second point. Although I suspect that Affero-like terms were very intentionally left out of the GPL as running applications remotely is not at all a new concept.
I mostly agree with you (err... see my signature), but I am not sure why your examples are actually problems. I find "cloud computing" more of an issue for services like GMail or Google Docs where private information is getting stored unencrypted with a third party. I do not think the fix is to kill "cloud computing", but to develop services that are (1) open source so they can be deployed internal to an organization or (2) encrypted server-side so there is no breach of privacy (or both). Some peer-to-peer distributed encrypted storage would be cool, but I don't think the part where the service runs on a specific web server is necessarily a problem.
I find it a bit silly that Twitter and Facebook are centralized, and I avoid using Facebook messages (if Facebook wants to read my e-mail, they can sniff the packets; they're probably sent in the clear anyway), but I am not sure what the privacy concerns are with those services being centralized. They are both mainly for posting more or less public information. I would consider actual friends lists private information, but pretty much everyone I know has pretty much everyone they have ever met who has a Facebook on their friends list (possibly along a few they have never met), so that information is sufficiently dilute to be nearly worthless.
we open ourselves to identity theft on a scale unimagined.
If you can get credit in a person's name using the information in their Facebook profile, then the problem lies with identify verification system. The fact that the information is more accessible now just makes the problem more visible.
There have been very small quantum computers demonstrated. IBM made a 7-qubit one and ran Shor's algorithm (for polynomial-time factoring) on it in 2001. As far as I can tell, that is the highest number of qubits anyone has demonstrated in a quantum computer.
The main evolutionary reaction to incest is the Westermarck effect, which basically means that people usually are not sexually attracted to anyone they spent a significant amount of time around during the first six years of their life. As that usually includes their parents and siblings, it greatly discourages incest.
There are other posts on this thread suggesting that teenage rebellion only occurs in some cultures, so biological evolution does not explain it, although you could perhaps argue that cultural evolution does... but I am not really sure how that would work.
Hmmm... I agree that the assumption that the brain's working are "mechanical" is non-trivial, but I am not aware of any reason to believe it is false. You seem to be stating that it is an undisputed fact that the brain's workings are not "mechanical". Why? Do you have a source for this?
Here, let me clarify it for you. I hereby 'declare' as a key assumption that the Heisenberg Uncertinty principle is an important part of how nuerons work.
Okay, you just made the simulation much, much more computationally expensive. But not impossible.
Folding@home and other computational biology projects assume that various biological processes can be correctly simulated by a computer (and they can verify those results by looking at experimental data. To suggest that is not the case for the brain would require further proof.
In fact, the best way I can think of to test if the brain can be simulation is to build what should be a simulation of a brain if it can be and see if it acts anything like a real brain. It seems like simulating the brain of an animal with fewer brain cells (ex. a fruit fly) would be a reasonable simplified experiment, although it would be reasonable to argue that fruit fly brains work a lot differently than human brains so successfully simulating a fruit fly would not necessarily mean you could successfully simulate a human (although it would probably still give useful information about brains in general).
The basic problem with all the 'we can copy the brain' ideas is the basic assumption that 'it is a purely mechanical process'. That is kind of like saying "If we assume a box is made of wood, then we can build one out of a tree." No duh sherlock, but the basic thing we are arguing about is the thing you rather arrogantly assumped was true.
I did not mean to make such a trivial statement. I was giving an explanation of why what you said originally does not immediately make simulating a brain impossible: we can simulate something we don't understand. One of the goals of simulating the brain / parts of the brain is to attempt to understand it better. For example, with a real brain, using an MRI machine, one can get moderately good images of what the brain is doing, but no where near perfect. If the neurons are simulated, then finding the state of a neuron at any point in a (repeatable) simulation is trivial.
What the poster/article discusses is not in anyway close to being a worthwhile simulation of the brain in the way they imply.
Yes, we are probably at least 10-20 years away from the processing power to simulate every neuron in a human brain at a reasonable speed.
See: the Church-Turing thesis. Basically, a sufficiently powerful computer can emulate anything. Along with some simple assumptions about the nature of the physics which apply to the human body, that includes fully simulating a human brain.
On the other hand, the fact that the human brain's computations are analog instead of digital makes using normal CPUs for emulating brain cells very inefficient, hence the project mentioned in the summary to build specialized hardware for the purpose.
Not understanding the brain at all levels does not make it impossible to simulate. See: Emergence. Simulating the brain comes down to choosing a level to build the simulation at and collecting enough information about the structure of the brain at that level to actually run the simulation. Choosing the level of atoms/molecules would be far too computationally expensive (and quite difficult to collect data for), so instead the scientists are using the level of neurons, which there are various ways to get limited information about -- including running small simulations and seeing if the results match a similar lab test. On the other hand, trying simulate entire sections of the brain at once (instead of building such a simulation out of simulated neurons) is beyond our understanding of the brain.
Yes, of course. Sorry, I did not mean to imply that Google should be expected to be give away services for free without advertising.
That is, the details of how much CPU are used by the IO system aren't written to the process header, because the process header isn't in the computable scope (an area defined by a set of active register values). Ergo, "top" doesn't report that CPU because it isn't there.
You can get some idea of that usage by looking at the "Cpu(s):" line in top. Specifically, "sy"=system (kernel) time and wa and hi are related to time dealing with hardware. See man top for more details. That information is not separated out by process, but you will be able to tell the difference between a program at 30% CPU usage because it is just not doing much and a program at 30% CPU usage because the processor is busy with other tasks (possibly the I/O for that process).
I recommend using htop as it gives a visual with all of the different types of CPU usage in different colors so you can get the information at a glance (and it can separate it by CPU/core).