Re:"Digital Ready" headphones -- for digital ears?
on
Truth in Advertising?
·
· Score: 1
I don't know what these amps do. I distinctly remember reading an article that mentioned using the speakers themselves as the filters, but that was years ago. I can't find it now.
It is possible the article referred to a specific amp/speaker comination that was tuned, or just matched to work together. Most crossovers already have low pass filters on woofers and midrange, so that may not have been a concern, and as you say, some tweeters may not need the filter at all.
On the other hand, I suspect you're correct, and these amps probably do have some low pass output filter. The filters would make the amps safer, and more predictable, and there is probably no good reason against having them.
Re:"Digital Ready" headphones -- for digital ears?
on
Truth in Advertising?
·
· Score: 2, Informative
Actually, you're not far from describing a digital amplifier (such as Bel Canto and Spectron).
These amps generate a high frequency digital signal, which is pulse width modulated. Ordinary transducers cannot reproduce individual pulses due their inertia, but they do get "nudged" a little by each pulse. In affect, the transducer will average the signal out, converting the high frequency digital signal into a low frequency analog one -- the audio.
I prefer using my bluetooth phone for the same purpose. Is there anything similar to sailing clicker for linux? Before anyone gets worked up about the potential differences in security, let me say that I only want to lock my computer when I walk away. I wouldn't voluntarily use any device as the sole means of authentication, and I don't have anything that would be made more secure by such a device.
I agree that UDP could be used similarly to port knocking. Both methods will serve equally well when the attacker is unaware of the method you choose to use. (true security through obsecurity). I also agree that both methods are equally vulnerable if the attacker can sniff your network traffic, and they can get in by replaying the requests.
However, lets assume that the security daemons are *not* vulnerable to replay type attacks becuase we use one time pads, or computed keys or something. In this case, sniffing will tell the attacker what method is in use, but it won't allow them to get in by simply repeating a successful login sequence. Are the methods still equivalent?
I would think that port knocking would still be safer of the two. The port knocking monitor is still sitting behind the firewall, isolated from the network traffic. It would be more difficult to induce a failure in the monitor. Even if the monitor failed, the security would revert to the firewall -- which means you don't get in.
On the other hand, your UDP daemon would have to be written just as carefully as the services you are trying to protect. A buffer overflow, or any similar flaws in your daemon could allow someone to break in through your daemon. And such a flaw could be exploited blindly too -- all the attacker would have to suspect is that you are using a flawed daemon.
My distro behaves as you described; I stand corrected. I was thinking of "bad interpreter" error bash gives, but I must have seen that on files with a shebang or shebnag-like line but bad path.
> Hell, I could chmod my whatever.txt to +x and try it!! It will actually attempt to run that way! Not smart.
First of all, the statement is false, and second, windows is actually worse.
Add.com or.exe extension to any file in windows, and what have you got? Windows WILL try to run these "executables". Unlike linux, contrary to his claims. Linux also checks the content of the file before attempting to execute it -- a valid interpreter must be specified in the file(such as #!/bin/sh), or the file must have a magic code indicating the binary type.
As you and others mentioned, windows is only made less secure by the fact that extensions are hidden by default, and that any file saved with the right extensions (from urls, from attachments, etc.) is automatically executable.
Responses to my question included plenty of explanations (yours included, setting insults aside), that were not present when I posted my question. Do not take the following as further challanges to the article, the algorithms described, what a scheduler is; its simply a clarification for the example you felt deserved an insult. I might have tried too hard to reduce the sorting example to absurdity, but but the point remains the same.
Suppose an application needs to keep an ordered set of data. Further suppose that one implementation does this with quick sort every once in a while (does many insertions/delitions between sorts), and another implementation maintains the invariant of the sorted data set at each insertion/deltion with bubble sort. Obviously bubble sort is far from the best algorithm for this, but it is still suitable for sake of argument. Bubble sort can maintain the invariant in at most n steps per operation. On the other hand, quick sort needs nlogn steps to sort the data. If sorting is done infrequently enough, then quicksort will be faster overall (nlogn vs n^2). Which implementation is better? If you criteria is to minimize the worst delay, or to amortize the cost of sorting over each operation, then the bubble sort implementation will behave "better" then the quick sort one. However, comarping these two implementations without stating your criteria or qualifications does not give you the license to call bubble sort an O(n) algorithm in the same breath as calling quick sort an O(nlogn) algorithm. It would appear an apples to oranges comparison.
The article compared two algorithms. One that ran once for each timeslice taking a constant time, and another that ran once for every n timeslices, taking time proportional to n. Without further explanation, or your defininition for what the scheduler is, it was not clear why one could be called O(1) while the other was called O(n).
You're probably right, and if that is the case, then the answser is perfectly clear.
It just sounded like 2.4 scheduler didn't have to do any work until all timeslices were used up, then it figured out what processes should run next, wait until they all run, and so on.
it sounded like the 2.4 scheduler scaned once for every n process running, taking time proportional to n, while the 2.6 does it for each process taking a constant time. in other words, the old process runs less frequently but longer, the new one more frequently but shorter. it was not explained (though should have been obvious) why one approach was necesserily better then the other.
Well, the scheduler spends roughly the same amount of time scheduling a thread irrespective of the number of runnable processes, so it's O(1).
Well, based on the description I could also argue the same for the old scheduler. Isn't 1*O(n) = n*O(1), with n being the number of runnable processes? In the end, they both consume the same amount of CPU time regardless of n. I was hoping there was more, so I could learn some magic (sufficiently advanced techniques), and because I feel it is misleading to call this O(1) without qualifications or explanation.
You could call it O(n), with n being the number of timeslices, but that's silly.
True... And sorry, but I can't resist a silly reponse. There is an O(1) sort function, if only you don't expect a sorted array after a single call, and if you're willing to ignore how many times you will call sort, and if you only care about characterizing a single unit of work with the O() expression... If there was a suitable application for this algorithm, where the most important consideration was how long a single step of the sort process took, would that justify calling the algorithm O(1)?
No question, I agree that a small calculation per process is better then a large, non-interruptible one every now and then. I just thought there might be something else I missed. Thanks for the response!
The mechanism for recalculation of timeslices in previous Linux kernel's was very simple. When every process had its timeslice completely depleted (they were all 0) the kernel would simply go through every process and recalculate its timeslice and start execution again at the highest priority runnable process. While this is the most obvious solution it is also very inefficient, executing in O(n) time.
Ok, its easy to see why this is O(n).
The 2.6 scheduler uses a simple yet effective method for getting rid of this problem, it uses two priority arrays! One priority array is for processes that are runnable, and one priority array is for processes that are not runnable (they have depleted their timeslice). This way if when a process has depleted its timeslice the scheduler simply recalculates its timeslice, removes it from the active array, and inserts it into the expired array.
How is this not O(n)? The time slice calculation still occurs for each process, just not all at once for all processes. Each process still gets its time slice calcuated, it is removed from one queue, and inserted into another. Is there some other unmentioned trick that eliminates the calculations? Or was there something else that made the 2.4 scheduler O(n), such as finding the highest priority process?
So when all processes have depleted their timeslices there is no need to recalculate timeslices for every process, the two arrays are just switched (for the code oriented among us: they are accessed via pointers and the pointers are simply switched).
So the calculation is done per process as they finish their time slice, rather then at the end when all the processes are done. I still don't see why this would imply better efficiency. Am I missing something?
At any rate, thanks for the link, it was much more informative than the published article.
You're absolutly right. The photo ID did the trick for me, it put our discussion in a whole new perspective. I feel embarrassed, but I did not think of it before.
I don't see a description. All I see is an assertion.
OK, did a little more google. Here are a couple of real source articles.
And you are forgetting that I already stated that fingerprints were a bad example. For fingerprints, fine, they're already being used, and they're easy to copy. So let's not use them for anything else. But that's a strawman argument against a single implementation of biometrics.
Fingerprints do make a convenient strawman, but unfortunately they are still the dominant form of biometric systems. Look around you, count the products or services that propose to rely on biometrics. The majority (60% according to the latest article linked from slashdot) is fingerprint based. The next largest group is facial recognition, which is also not very secure. The rest (hand, iris, voice, writing) may or may not be better, I do not know. Combination systems are very rare today. Don't you think the strawman arguments are valid while the strawman is real?:)
If an ATM used [fingerprints], and your fingerprints were stolen, there's no way you could be personally held responsible unless you were somehow negligent. This protection is being used by the bank, not by the person, so there isn't "anything else that might be protected by that ID," as far as the victim is concerned.
So fine, the fingerprint is for the protection of the bank, and I won't be liable if their system turns out to be less then secure. There is also no harm done if the bank is the only one entity in my lifetime (or in the lifetime of a given technology) that uses that biometric. But there are not enough unique biometric systems that each bank, each id card, each company could use an independent measurement, so there will be inevitable overlaps.
If [birth certificates, passports, etc.] were required day to day, they wouldn't be sufficient to "steal my identity." Actually, the whole concept of "stealing someone's identity" is rather ridiculous. For instance, this article talks about stealing people's identity's, but what actually happened is people stole a bunch of cash from an ATM.
This is a good argument. As long as the compromised systems are compartmentalized (ie. one bank and their atms) then such a compromise is not a big deal. The problem comes if multiple systems will depend on the same biometric id.
The way I think about them is like a public/private key system that you cannot change. Biometrics are easy to recognize, but hard to reproduce. That's the key to their security.
As long as they are difficult to reproduce, I agree. In my opinion though there is a limited window when that is true. Once someone figures out how to do it, then that given biometric will become weaker.
Keep in mind that the difficulty only exists for physical attacks, where a person is trying to impersonate you in front of a trusted system. Biometric signatures offer no protection against electronic attacks. If these rigged ATMs can copy the PIN number and magnetic card info in a re-usable form, then they can also copy your biometric signature.
No one is forcing people to use biometrics on anything.
Oh, good, I'm relieved.:) "use it at your own risk" (whether that risk is lower or higher then alternatives) is fine with me.
The private key is "me," perhaps. But the public key, which I give out is not me. It's the parts of me that are recorded in those particular conditions at that particular time. And that's not going to be the same among different systems.
Unlike in public key cryptography, it only matters if someone can produce a good imitation of your public "image
I don't see how they are trivial to copy. I want to copy my fingerprint. How can I do this?
I posted the link earlier, but here it is again from the cryptogram.
Umm, what if they wanted to commit a crime and frame you for it?
It could happen, but I consider it higly unlikely. At the moment those fingerprints would have to be stolen from the gov, or from my immediate sorroundings. In other words, I would probably be a specific target. That is a lot less likely than getting scamed indiscriminately along with thousands or millions of other people.
No, it would only be good on all systems which do not have greater accuracy than the one used to capture your fingerprint. In other words, it would work today, not in the future.
Agreed, but nevertheless, you would still have to wait for that newer and improved system before you could restore faith in the given biometric scan. And again, it would only be a metter of time before you'd have to start over again.
Any system which relied solely on fingerprints is a bad system, clearly. But that doesn't mean that fingerprints don't add security to a system which already has other checks.
Besides, you've picked pretty much the least secure biometric system out there.
I did, clearly, for arguments sake.:) Fingerprints and fingerprint scaners have been around long enough to have known weaknesses. Newer biometric systems are not inherently better then fingerprints, just because we are not yet aware of their weaknesses and possible exploits. Only exposure to determined attackers and time will tell.
I fail to see the risk. You're saying that a system which uses a biometric identification in addition to the current identification schemes is risky, because that biometric identification might fail. That makes absolutely no sense to me. If it's an additional check, it can only enhance security. Depending on the details of the scheme, it might not provide enough additional security to be worth the price and/or hassle, but that's a completely different story altogether.
I see the added security and the risk as two different things. The added security is that my account is less likely to be hacked, because the bar is higher. That is obviously good. The bad part is that now you have more to protect, and the potential damages of a security breach are higher -- besides a few hundred bucks in a checking account, now you also have to worry about your irreplacable biometric ID and anything else that might be protected by that ID. How much risk I precieve would be directly related to what else might be tied to that biometric ID -- including future use of the compromised service until a newer, improved authentican system can replace the compromised one.
The way I think about biometric IDs is more like passwords that you cannot change. You think a second password on your online bank account would make it more secure? Sure it could... What if you were forced to use that same password on random websites, vending machines, other email accounts, other online bank accounts, etc? Each of those may be protected by something else unique -- such as a different username and perhaps another pin number -- but have the same unchangable password. Assuming that you can reasonably expect that password to get recorded somewhere, do you think it would still increase your security? I don't. I rather have passwords I can keep independent and that can be changed to limit any damages.
Basically, you're afraid to use your fingerprint for identification, because then people will find out your fingerprint, and then you can't use it for identification. I don't get it.
You are forgetting that fingerprints are already used for identification, and in rather serious contexts. It makes perfect sense not to get them mixed up in trivial day to day
My problem is with imperfect biometrics -- and I fear that all systems are imperfect, even if their designers believe or claim otherwise.
Take fingerprints for example. They are trivial to copy, and they can be recreated from digital scans or photos. There is no practical reason why anyone should want to copy or fake my fingerprints today, so I'm OK if it is used in some limited context like INS or FBI records. The chance that someone else would fake (or match!) my fingerprints are so small that I feel confident I will not be falsely identified. On the other hand, if fingerprint based identification became popular (and in case of ATMs, if it led to cash out of my account), then there would be great incentive for criminals to capture it from a compromised scanner somewhere. The stolen fingerprint would be good on _all_ systems that used fingerpritns for identification, today and in the future, not just the one it was stolen from. I'd have no recouse to get back my previous level of security (or a systems trust in my identity), except to wait until all affected systems were replaced (even legal systems) or sufficiently improved.
Some of my concerns would be addressed by different biometric systems in combination with more conventional security measures. I even think they would be more secure than current conventional systems... But I think the risks I would be exposed to would be greater, and the potential damage from a compromise would be greater, and I don't think that would be worth the added security.
If ATMs recognized people like their significant others do, or if the attacker actually had to masquerade in front of another person, then I'd agree with you. But that is hardly the case with ATMs and similar unattended systems. An exact replica of a person is not required to fool one or two biometric scans.
Voiceprints, fingerprints, face recognition have been proven to be insecure. Other forms of biometrics might look more promising, but they might simply be unproven. Do you want to give criminals the incentive and the means to catpure any information about you that cannot be changed? Biometrics that could be used to incrimante (like DNA, or fingerprints) are especially worrysome. Do you think that the police, FBI, courts and everyone else will stop using these biometrics if one such system is compromised?
Re:I try to avoid them altogether.
on
Fake ATM Fraud Expose
·
· Score: 5, Insightful
Biometrics won't change the difficulty of electronic attacks, where the biometric signature is copied as easily as your pin number. Biometrics might make physical attacks more difficult, but still not impossible. Time and time again it is shown that biometric systems do not live up to hype. Sometimes they can be easily fooled, and sometimes the biometric signature can be used to reconstruct an acceptable fake. You can count on someone figuring out how to explit any given system sooner or later. How will you restore your security then? Can you get new fingerprints, or new eyeballs?
I see your point, and I tend to agree. This system may be a lot better than anything else, but it will be tought to sell. Why should politicians want to use it, unless fraud becomes a very hot topic? Why should the public trust it if they do not understand it? I have some faith that people will accept the system if it is explained to them in the right terms, but I'm not sure if they'll get an opportunity for that education.
The video thing was a mataphor. Its all electronic. The "trustee" runs a simple program that does the decryption and shuffling of the ballots using their private key. A random 50% of those transformations get published. Anyone can verify the correctness of the decryption process backwards -- take the decrypted ballot and encrypt it with the trustees public key. If the transformation was clean then you get the original encrypted ballots back. You get something else if they cheated. If you have enough trustees in the process then you cannot trace any given ballot to its final decrypted form, but you can almost certainly detect any tempering.
The proposed system addresses your concerns, and others that you are blissfully unaware of.
1. The receipt does not allow anyone to determine how you voted. To figure that out, you'd need every single private key used by the election "trustees".
2. You can verify that your vote was not tempered with, and that it was included in the tally as you cast it.
Your suggestion requires that we blindly trust the counting and transmission and final tallying of the votes, and that noone can temper with or substitute sealed ballots. In addition, there would be no traces of tempering if it occured, and there are no means for anyone to verify the corectness of the voting process without a manual recount. In other words, it isn't any more secure than the systems in use today.
If you read (and understand) the article, you'll realize that the complexity is worth it -- it guarantees that any single altered vote will have at least a 50% chance of being detected. Temper with more than a few dozen, and you're more likely to win the lottery than to get away with it undetected.
If the system lives up to its claims then this is unprecedented, and far better than any voting system we have had to date.
Slashdot Mirror
I don't know what these amps do. I distinctly remember reading an article that mentioned using the speakers themselves as the filters, but that was years ago. I can't find it now.
It is possible the article referred to a specific amp/speaker comination that was tuned, or just matched to work together. Most crossovers already have low pass filters on woofers and midrange, so that may not have been a concern, and as you say, some tweeters may not need the filter at all.
On the other hand, I suspect you're correct, and these amps probably do have some low pass output filter. The filters would make the amps safer, and more predictable, and there is probably no good reason against having them.
Actually, you're not far from describing a digital amplifier (such as Bel Canto and Spectron).
These amps generate a high frequency digital signal, which is pulse width modulated. Ordinary transducers cannot reproduce individual pulses due their inertia, but they do get "nudged" a little by each pulse. In affect, the transducer will average the signal out, converting the high frequency digital signal into a low frequency analog one -- the audio.
I prefer using my bluetooth phone for the same purpose. Is there anything similar to sailing clicker for linux? Before anyone gets worked up about the potential differences in security, let me say that I only want to lock my computer when I walk away. I wouldn't voluntarily use any device as the sole means of authentication, and I don't have anything that would be made more secure by such a device.
- Use of browsers for eCommerce (Oracle patent)
How is this issue specific to linux?
I agree that UDP could be used similarly to port knocking. Both methods will serve equally well when the attacker is unaware of the method you choose to use. (true security through obsecurity). I also agree that both methods are equally vulnerable if the attacker can sniff your network traffic, and they can get in by replaying the requests.
However, lets assume that the security daemons are *not* vulnerable to replay type attacks becuase we use one time pads, or computed keys or something. In this case, sniffing will tell the attacker what method is in use, but it won't allow them to get in by simply repeating a successful login sequence. Are the methods still equivalent?
I would think that port knocking would still be safer of the two. The port knocking monitor is still sitting behind the firewall, isolated from the network traffic. It would be more difficult to induce a failure in the monitor. Even if the monitor failed, the security would revert to the firewall -- which means you don't get in.
On the other hand, your UDP daemon would have to be written just as carefully as the services you are trying to protect. A buffer overflow, or any similar flaws in your daemon could allow someone to break in through your daemon. And such a flaw could be exploited blindly too -- all the attacker would have to suspect is that you are using a flawed daemon.
Am I wrong?
What does this laptop offer that you can't find in other 7-10lbs laptops?
My distro behaves as you described; I stand corrected. I was thinking of "bad interpreter" error bash gives, but I must have seen that on files with a shebang or shebnag-like line but bad path.
Windows XP doesn't complain, just opens a dos window and hangs. r,
> Hell, I could chmod my whatever.txt to +x and try it!! It will actually attempt to run that way! Not smart.
.com or .exe extension to any file in windows, and what have you got? Windows WILL try to run these "executables". Unlike linux, contrary to his claims. Linux also checks the content of the file before attempting to execute it -- a valid interpreter must be specified in the file(such as #!/bin/sh), or the file must have a magic code indicating the binary type.
First of all, the statement is false, and second, windows is actually worse.
Add
As you and others mentioned, windows is only made less secure by the fact that extensions are hidden by default, and that any file saved with the right extensions (from urls, from attachments, etc.) is automatically executable.
Responses to my question included plenty of explanations (yours included, setting insults aside), that were not present when I posted my question. Do not take the following as further challanges to the article, the algorithms described, what a scheduler is; its simply a clarification for the example you felt deserved an insult. I might have tried too hard to reduce the sorting example to absurdity, but but the point remains the same.
Suppose an application needs to keep an ordered set of data. Further suppose that one implementation does this with quick sort every once in a while (does many insertions/delitions between sorts), and another implementation maintains the invariant of the sorted data set at each insertion/deltion with bubble sort. Obviously bubble sort is far from the best algorithm for this, but it is still suitable for sake of argument. Bubble sort can maintain the invariant in at most n steps per operation. On the other hand, quick sort needs nlogn steps to sort the data. If sorting is done infrequently enough, then quicksort will be faster overall (nlogn vs n^2). Which implementation is better? If you criteria is to minimize the worst delay, or to amortize the cost of sorting over each operation, then the bubble sort implementation will behave "better" then the quick sort one. However, comarping these two implementations without stating your criteria or qualifications does not give you the license to call bubble sort an O(n) algorithm in the same breath as calling quick sort an O(nlogn) algorithm. It would appear an apples to oranges comparison.
The article compared two algorithms. One that ran once for each timeslice taking a constant time, and another that ran once for every n timeslices, taking time proportional to n. Without further explanation, or your defininition for what the scheduler is, it was not clear why one could be called O(1) while the other was called O(n).
You're probably right, and if that is the case, then the answser is perfectly clear.
It just sounded like 2.4 scheduler didn't have to do any work until all timeslices were used up, then it figured out what processes should run next, wait until they all run, and so on.
it sounded like the 2.4 scheduler scaned once for every n process running, taking time proportional to n, while the 2.6 does it for each process taking a constant time. in other words, the old process runs less frequently but longer, the new one more frequently but shorter. it was not explained (though should have been obvious) why one approach was necesserily better then the other.
Well, the scheduler spends roughly the same amount of time scheduling a thread irrespective of the number of runnable processes, so it's O(1).
Well, based on the description I could also argue the same for the old scheduler. Isn't 1*O(n) = n*O(1), with n being the number of runnable processes? In the end, they both consume the same amount of CPU time regardless of n. I was hoping there was more, so I could learn some magic (sufficiently advanced techniques), and because I feel it is misleading to call this O(1) without qualifications or explanation.
You could call it O(n), with n being the number of timeslices, but that's silly.
True... And sorry, but I can't resist a silly reponse. There is an O(1) sort function, if only you don't expect a sorted array after a single call, and if you're willing to ignore how many times you will call sort, and if you only care about characterizing a single unit of work with the O() expression... If there was a suitable application for this algorithm, where the most important consideration was how long a single step of the sort process took, would that justify calling the algorithm O(1)?
No question, I agree that a small calculation per process is better then a large, non-interruptible one every now and then. I just thought there might be something else I missed. Thanks for the response!
The mechanism for recalculation of timeslices in previous Linux kernel's was very simple. When every process had its timeslice completely depleted (they were all 0) the kernel would simply go through every process and recalculate its timeslice and start execution again at the highest priority runnable process. While this is the most obvious solution it is also very inefficient, executing in O(n) time.
Ok, its easy to see why this is O(n).
The 2.6 scheduler uses a simple yet effective method for getting rid of this problem, it uses two priority arrays! One priority array is for processes that are runnable, and one priority array is for processes that are not runnable (they have depleted their timeslice). This way if when a process has depleted its timeslice the scheduler simply recalculates its timeslice, removes it from the active array, and inserts it into the expired array.
How is this not O(n)? The time slice calculation still occurs for each process, just not all at once for all processes. Each process still gets its time slice calcuated, it is removed from one queue, and inserted into another. Is there some other unmentioned trick that eliminates the calculations? Or was there something else that made the 2.4 scheduler O(n), such as finding the highest priority process?
So when all processes have depleted their timeslices there is no need to recalculate timeslices for every process, the two arrays are just switched (for the code oriented among us: they are accessed via pointers and the pointers are simply switched).
So the calculation is done per process as they finish their time slice, rather then at the end when all the processes are done. I still don't see why this would imply better efficiency. Am I missing something?
At any rate, thanks for the link, it was much more informative than the published article.
You're absolutly right. The photo ID did the trick for me, it put our discussion in a whole new perspective. I feel embarrassed, but I did not think of it before.
Thanks for the enlightenment!
I don't see a description. All I see is an assertion.
:)
:) "use it at your own risk" (whether that risk is lower or higher then alternatives) is fine with me.
OK, did a little more google. Here are a couple of real source articles.
And you are forgetting that I already stated that fingerprints were a bad example. For fingerprints, fine, they're already being used, and they're easy to copy. So let's not use them for anything else. But that's a strawman argument against a single implementation of biometrics.
Fingerprints do make a convenient strawman, but unfortunately they are still the dominant form of biometric systems. Look around you, count the products or services that propose to rely on biometrics. The majority (60% according to the latest article linked from slashdot) is fingerprint based. The next largest group is facial recognition, which is also not very secure. The rest (hand, iris, voice, writing) may or may not be better, I do not know. Combination systems are very rare today. Don't you think the strawman arguments are valid while the strawman is real?
If an ATM used [fingerprints], and your fingerprints were stolen, there's no way you could be personally held responsible unless you were somehow negligent. This protection is being used by the bank, not by the person, so there isn't "anything else that might be protected by that ID," as far as the victim is concerned.
So fine, the fingerprint is for the protection of the bank, and I won't be liable if their system turns out to be less then secure. There is also no harm done if the bank is the only one entity in my lifetime (or in the lifetime of a given technology) that uses that biometric. But there are not enough unique biometric systems that each bank, each id card, each company could use an independent measurement, so there will be inevitable overlaps.
If [birth certificates, passports, etc.] were required day to day, they wouldn't be sufficient to "steal my identity." Actually, the whole concept of "stealing someone's identity" is rather ridiculous. For instance, this article talks about stealing people's identity's, but what actually happened is people stole a bunch of cash from an ATM.
This is a good argument. As long as the compromised systems are compartmentalized (ie. one bank and their atms) then such a compromise is not a big deal. The problem comes if multiple systems will depend on the same biometric id.
The way I think about them is like a public/private key system that you cannot change. Biometrics are easy to recognize, but hard to reproduce. That's the key to their security.
As long as they are difficult to reproduce, I agree. In my opinion though there is a limited window when that is true. Once someone figures out how to do it, then that given biometric will become weaker.
Keep in mind that the difficulty only exists for physical attacks, where a person is trying to impersonate you in front of a trusted system. Biometric signatures offer no protection against electronic attacks. If these rigged ATMs can copy the PIN number and magnetic card info in a re-usable form, then they can also copy your biometric signature.
No one is forcing people to use biometrics on anything.
Oh, good, I'm relieved.
The private key is "me," perhaps. But the public key, which I give out is not me. It's the parts of me that are recorded in those particular conditions at that particular time. And that's not going to be the same among different systems.
Unlike in public key cryptography, it only matters if someone can produce a good imitation of your public "image
I don't see how they are trivial to copy. I want to copy my fingerprint. How can I do this?
:) Fingerprints and fingerprint scaners have been around long enough to have known weaknesses. Newer biometric systems are not inherently better then fingerprints, just because we are not yet aware of their weaknesses and possible exploits. Only exposure to determined attackers and time will tell.
I posted the link earlier, but here it is again from the cryptogram.
Umm, what if they wanted to commit a crime and frame you for it?
It could happen, but I consider it higly unlikely. At the moment those fingerprints would have to be stolen from the gov, or from my immediate sorroundings. In other words, I would probably be a specific target. That is a lot less likely than getting scamed indiscriminately along with thousands or millions of other people.
No, it would only be good on all systems which do not have greater accuracy than the one used to capture your fingerprint. In other words, it would work today, not in the future.
Agreed, but nevertheless, you would still have to wait for that newer and improved system before you could restore faith in the given biometric scan. And again, it would only be a metter of time before you'd have to start over again.
Any system which relied solely on fingerprints is a bad system, clearly. But that doesn't mean that fingerprints don't add security to a system which already has other checks.
Besides, you've picked pretty much the least secure biometric system out there.
I did, clearly, for arguments sake.
I fail to see the risk. You're saying that a system which uses a biometric identification in addition to the current identification schemes is risky, because that biometric identification might fail. That makes absolutely no sense to me. If it's an additional check, it can only enhance security. Depending on the details of the scheme, it might not provide enough additional security to be worth the price and/or hassle, but that's a completely different story altogether.
I see the added security and the risk as two different things. The added security is that my account is less likely to be hacked, because the bar is higher. That is obviously good. The bad part is that now you have more to protect, and the potential damages of a security breach are higher -- besides a few hundred bucks in a checking account, now you also have to worry about your irreplacable biometric ID and anything else that might be protected by that ID. How much risk I precieve would be directly related to what else might be tied to that biometric ID -- including future use of the compromised service until a newer, improved authentican system can replace the compromised one.
The way I think about biometric IDs is more like passwords that you cannot change. You think a second password on your online bank account would make it more secure? Sure it could... What if you were forced to use that same password on random websites, vending machines, other email accounts, other online bank accounts, etc? Each of those may be protected by something else unique -- such as a different username and perhaps another pin number -- but have the same unchangable password. Assuming that you can reasonably expect that password to get recorded somewhere, do you think it would still increase your security? I don't. I rather have passwords I can keep independent and that can be changed to limit any damages.
Basically, you're afraid to use your fingerprint for identification, because then people will find out your fingerprint, and then you can't use it for identification. I don't get it.
You are forgetting that fingerprints are already used for identification, and in rather serious contexts. It makes perfect sense not to get them mixed up in trivial day to day
My problem is with imperfect biometrics -- and I fear that all systems are imperfect, even if their designers believe or claim otherwise.
Take fingerprints for example. They are trivial to copy, and they can be recreated from digital scans or photos. There is no practical reason why anyone should want to copy or fake my fingerprints today, so I'm OK if it is used in some limited context like INS or FBI records. The chance that someone else would fake (or match!) my fingerprints are so small that I feel confident I will not be falsely identified. On the other hand, if fingerprint based identification became popular (and in case of ATMs, if it led to cash out of my account), then there would be great incentive for criminals to capture it from a compromised scanner somewhere. The stolen fingerprint would be good on _all_ systems that used fingerpritns for identification, today and in the future, not just the one it was stolen from. I'd have no recouse to get back my previous level of security (or a systems trust in my identity), except to wait until all affected systems were replaced (even legal systems) or sufficiently improved.
Some of my concerns would be addressed by different biometric systems in combination with more conventional security measures. I even think they would be more secure than current conventional systems... But I think the risks I would be exposed to would be greater, and the potential damage from a compromise would be greater, and I don't think that would be worth the added security.
If ATMs recognized people like their significant others do, or if the attacker actually had to masquerade in front of another person, then I'd agree with you. But that is hardly the case with ATMs and similar unattended systems. An exact replica of a person is not required to fool one or two biometric scans.
Voiceprints, fingerprints, face recognition have been proven to be insecure. Other forms of biometrics might look more promising, but they might simply be unproven. Do you want to give criminals the incentive and the means to catpure any information about you that cannot be changed? Biometrics that could be used to incrimante (like DNA, or fingerprints) are especially worrysome. Do you think that the police, FBI, courts and everyone else will stop using these biometrics if one such system is compromised?
Biometrics won't change the difficulty of electronic attacks, where the biometric signature is copied as easily as your pin number. Biometrics might make physical attacks more difficult, but still not impossible. Time and time again it is shown that biometric systems do not live up to hype. Sometimes they can be easily fooled, and sometimes the biometric signature can be used to reconstruct an acceptable fake. You can count on someone figuring out how to explit any given system sooner or later. How will you restore your security then? Can you get new fingerprints, or new eyeballs?
I see your point, and I tend to agree. This system may be a lot better than anything else, but it will be tought to sell. Why should politicians want to use it, unless fraud becomes a very hot topic? Why should the public trust it if they do not understand it? I have some faith that people will accept the system if it is explained to them in the right terms, but I'm not sure if they'll get an opportunity for that education.
The video thing was a mataphor. Its all electronic. The "trustee" runs a simple program that does the decryption and shuffling of the ballots using their private key. A random 50% of those transformations get published. Anyone can verify the correctness of the decryption process backwards -- take the decrypted ballot and encrypt it with the trustees public key. If the transformation was clean then you get the original encrypted ballots back. You get something else if they cheated. If you have enough trustees in the process then you cannot trace any given ballot to its final decrypted form, but you can almost certainly detect any tempering.
The proposed system addresses your concerns, and others that you are blissfully unaware of.
1. The receipt does not allow anyone to determine how you voted. To figure that out, you'd need every single private key used by the election "trustees".
2. You can verify that your vote was not tempered with, and that it was included in the tally as you cast it.
Your suggestion requires that we blindly trust the counting and transmission and final tallying of the votes, and that noone can temper with or substitute sealed ballots. In addition, there would be no traces of tempering if it occured, and there are no means for anyone to verify the corectness of the voting process without a manual recount. In other words, it isn't any more secure than the systems in use today.
If you read (and understand) the article, you'll realize that the complexity is worth it -- it guarantees that any single altered vote will have at least a 50% chance of being detected. Temper with more than a few dozen, and you're more likely to win the lottery than to get away with it undetected.
If the system lives up to its claims then this is unprecedented, and far better than any voting system we have had to date.