If your credit card is stolen, you are only liable for the first $50 of fraudlent charges.
Debit cards give you NO such protection. If your debit card is stolen and used to drain your bank account, you have no recourse but to eat the losses.
Hmm, that's a pretty important issue. I wonder if the article addresses it:
The system also sets a maximum weekly limit of $300 in withdrawals, though Randazza says in the case of fraud, customers would only be responsible for the first $50 of that.
Hey, would you look at that!
(Note: calling this a 'debit card' is a slight abuse of the terminology. It works by an entirely different mechanism than a normal debit card. However, it has most of the properties of them, such as coming out of your bank account shortly after purchase (they use ACH so it won't clear immediately I think), but it's not strictly a debit card.)
So you're saying that currently people go jogging with their driver's license but not their credit card/debit card? I suppose this could be the case, but my impression of peoples' behavior is that you keep both in your wallet, then you have your wallet or not. Maybe there are some exceptions, like if you're going to a specific store you grab the CC for that store, but at least when I go around I either have both my driver's license and my credit and debit card, or I have none of them.
Which means there's no change in consolidating them from that perspective.
I refuse to use debit cards at all (as opposed to an ATM card or a credit card), because they draw directly from your account and they don't require an independent piece of verification (like a PIN) to use.
I'm glad that you're being moderated interesting for your very insightful comments that are substantiated by quotes from the article:
withdrawals are not permitted after more than three failed PIN attempts
Or how 'bout the caption of the picture:
two-year-old company called National Payment Card allows customers to pay for gas by swiping their driver's license and entering a PIN
Or a quote from a user:
Because her license is PIN-protected, she points out, it's even more secure than using a credit card.
How are you going to cancel your driver's license when the DMV is only open Monday through Friday 8-5?
You wouldn't need to cancel your driver's license, you would just disable your account. You wouldn't be able to get a new one until you go get a new driver's license number (do they even change those when you get a new card? if not then you wouldn't really be able to reopen your account), but then again, you don't get a new card right away either.
Holy God, did no one RTFA? Usually there are a few people who know what they're talking about.
Listen carefully. The government is not involved in this project. It is purely private enterprise overloading the meaning of your driver's license number.
In general, I have a bus pass, credit card, debit card, driver's license, student ID, and some other stuff that I actually have no need for (but isn't harmful to have either). That's 5 cards that I have a use for on a regular basis. I suppose I could cut off one of the credit or debit cards, but I like using the credit card for almost all purchases (I pay off the balance in full each month; it just lets me hold the money a little longer and builds credit) and I need something I can get cash with. Dropping a couple of those cards would be pretty nice.
alcohol, tobacco, skin mags, R-rated movies, and M-rated games (don't you just love how those last two are lumped in with the first three?)
I'm not sure how skin mags fall into a separate category from R movies and M games. I could see you saying "don't you just love how those last *three* are lumped in with the first two...
I wonder what something like this will do, when the key to free stuff now, and debt later, is right in your wallet at all times, and you have to carry it around.
Um, that's what most people do already.
Besides, methinks you're getting debit and credit cards confused. (Not that credit cards will probably be right on the heels.)
The child of Vista will "require" a 64-Bit CPU to boot but you can bet your bottom dollar that it will run 32 and even 16 bit code.
By my understanding, Vista has already dropped support for 16 bit code.
In Windows NT (generic term for NT, 2K, XP, Vista...), programs don't make direct system calls. In fact, the system call interface (called the Native API) is somewhat undocumented and completely unsupported. In fact, the Windows build process automatically generates system call numbers during each build. Instead, NT has a notion of subsystems that provide a "view" of the system calls through a different API. The one that 99% (this statistic from a study from Out Of My Ass, Inc.) of Windows programs use is called the Windows subsystem (previously the Win32 subsystem) because it provides Windows API calls (previously the Win32 API). In other words, the Windows subsystem translates Win32 API functions to NT system calls. For instance, CreateFile behind the scenes calls the NT function NtCreateFile. While named similarly, they have different arguments. In general, Win32 API functions may make no system calls or multiple system calls, and also do some other bookkeeping stuff.
(If you remember during the MS antitrust trial people were saying that Office had an unfair advantage because MS was using undocumented APIs -- I'm pretty sure that this is what they were talking about. And from what I hear, when the Windows team found out that the Office team was using their native API, they were none to happy.)
Anyway, the point of this is as follows. When you run a 16-bit program in the 32-bit version of NT, it does NOT run in the Windows subsystem. It runs in a different subsystem made for running 16-bit programs. (It's called Windows on Windows 16, or WOW16. If you look in your processes list and you run a 16-bit program, you'll see it there as wowexec.exe.) The same thing is true if you run 32-bit programs in 64-bit Windows: it runs in a separate subsystem, WOW64. (Don't ask me why it's not WOW32...)
Now, WOW16 is not shipped with 64-bit versions of Windows. Thus your support for DOS and Win3.1 applications (unless they use Win32s... wow, that's something I didn't think I'd say again) has *already* been dropped from 64-bit versions.
I suppose it's possible they'll add it back... but I doubt it.
The people who picket funerals are the "Westboro Baptist Church", headed by Fred Phelps. He is beyond the pale, and should no more be associated with the American religious right in general than Stalin should be associated with socialist politics.... Yes, Falwell said some stupid things--things that frustrated, embarrassed, and angered me as a theologically-conservative Christian. But please, do not associate Phelps' actions with anyone other than Fred Phelps.
Can I associate Phelps's actions with, I dunno, Satan? I think that's reasonable. At least to Phelps.
He or she is obviously more interested in personal wealth than the invention and than those in need of the invention. In the first scenario, if the invention did eventually get out, everyone could benefit from it, regardless of their wealth. The world would be a better place. In the second scenario, the inventor makes a killing, and the cure is held hostage, and only those willing to pay up will get the cure. The world is a better place for the inventor and the rich.
The first one is nice, but what if the alternative is NO cure? Then which is better, no cure, or greedy bastard's cure?
For really bright lights, a small square of aluminum foil works well, and is absolutely opaque.
Foil also works great as a blackout curtain. Made one out of foil and duct tape while I was in northern Norway with 24 hour sun for a month. Worked wonders.
(-j6 instead of -j4 in an effort to counter I/O latencies... Actually that'd be an interesting benchmark; figure out what the optimum level of parallelism is. Too little and processors will be idle, too much and context switches would become an issue.)
I looked at files in explorer. I changed the name of a file from, say, FOO.html to foo.html. Explorer told me it changed the name. It didn't. Opening a command window and typing dir showed the *actual* name of the file. move FOO.html foo.html *did* change the name.
That is badly broken behavior.
Hmm, what you describe is broken. Any chance you can figure out how to reproduce this so I can see if I can figure out what's going on? Not that I'd be able to do anything about it of course, I'm just curious.
None of your examples are similar at all.
Why aren't they?
(Well, at least why aren't they similar to the difference between case sensitivity and insensitivity; I can see why they could be considered different from the problem you are describing.)
Any thing that causes your computer to flat out lie to you is not worth having.
Hmm, that doesn't seem like a good argument to me.
First, whose to say that the problem you name isn't caused by Unix lying about whether "foo.html" and "Foo.html" are different files?
Second, your computer lies to you all the time. If you run a program, it's written in x86 instructions. But really you're executing microcode on uops. Should Intel go back and revamp their chips so that they are executing straight IA-32 without microcode?
Or open a calculator and type 3 + 4. Hey wait, the computer's lying to you! It can't actually add 3 and 4, it has to add 0000 0011 and 0000 1000 (or the word, dword, or qword version, or the floating point version). Should we say that those numbers are a lie, because they are actually stored in binary?
Or this text you're reading. It's actually stored and transmitted as ASCII numbers. Is it a lie to present a different view to you for ease of use?
Heck, the whole representation of binary in 0s and 1s is a lie. It's really just changes between voltage levels.
I think that we should have an interface to the computer where the output is a voltmeter and the input is you tapping the poles of a battery with a wire.
Where should the lies end? Why should they end with a case sensitive file system?
If you've got malicious code running that's able to create files with arbitrary names on your local file system, and perhaps even enable case sensitivity, you've got bigger problems than the names that code decides to use. It sounds to me like one of the typical examples of complaining that a machine that's already been compromised by a virus can be attacked by it: well, naturally.
Eh, but this is a common assumption, that the attacker has access to the computer. It's not so outlandish, and is one of the common security models.
It's not so much that a machine that's compromised can be attacked, it's that this feature raises the bar* on what the detector has to do to find it. Virus writers seem to be a little less disinclined to use undocumented/unsupported APIs to do their work than people who write security software. (Though the latter group is more inclined to use them than just about any other software I know of.)
* In XP and older, this feature isn't alone; streams cause the same problem. In Server 2003, Windows API functions FindFirstStream and FindNextStream were added which allow programs to enumerate alternate streams. This means that in 2K3 and Vista, this case sensitivity thing is the only reason I know of why a virus scanner would have to drop to the Native API.
To some extent I'm tempted to agree with your point about matching, i.e. that 'FOO' should match 'FOO', whether or not 'foo' also exists. However, you then run into a situation where the matching isn't actually case-insensitive. This means that two calls which are documented to have the same effect, e.g. open("foo") and open("FOO"), will actually have different results, so you've just exchanged one problem for another. On the whole, I think I'd actually lean towards having the same file always returned, if case insensitivity is enabled.
It's a good argument and I guess some usability testing would be in order. (For instance, do programs depend on opening files with differing case to end up the same file, and if they do, does always returning the same one fix it?)
I tend to suspect the tradeoff would go the other way, but then again, I haven't done the testing.
Slashdot Mirror
Debit cards give you NO such protection. If your debit card is stolen and used to drain your bank account, you have no recourse but to eat the losses.
Hmm, that's a pretty important issue. I wonder if the article addresses it:
Hey, would you look at that!
(Note: calling this a 'debit card' is a slight abuse of the terminology. It works by an entirely different mechanism than a normal debit card. However, it has most of the properties of them, such as coming out of your bank account shortly after purchase (they use ACH so it won't clear immediately I think), but it's not strictly a debit card.)
Without the end-user being able to revoke a stolen card
You would be able to disable the account.
If the DMV doesn't give you a new license number you wouldn't really be able to reopen it, but there is no issue with this system from that angle.
And none of that clear-text personalized info on the magstrip, thank you very much, NO!
Dunno if that's a general comment or specific to this system, but this adds no information to your license. In fact, it doesn't change it at all.
So you're saying that currently people go jogging with their driver's license but not their credit card/debit card? I suppose this could be the case, but my impression of peoples' behavior is that you keep both in your wallet, then you have your wallet or not. Maybe there are some exceptions, like if you're going to a specific store you grab the CC for that store, but at least when I go around I either have both my driver's license and my credit and debit card, or I have none of them.
Which means there's no change in consolidating them from that perspective.
I'm glad that you're being moderated interesting for your very insightful comments that are substantiated by quotes from the article:
Or how 'bout the caption of the picture:
Or a quote from a user:
How are you going to cancel your driver's license when the DMV is only open Monday through Friday 8-5?
You wouldn't need to cancel your driver's license, you would just disable your account. You wouldn't be able to get a new one until you go get a new driver's license number (do they even change those when you get a new card? if not then you wouldn't really be able to reopen your account), but then again, you don't get a new card right away either.
Holy God, did no one RTFA? Usually there are a few people who know what they're talking about.
Listen carefully. The government is not involved in this project. It is purely private enterprise overloading the meaning of your driver's license number.
It's not like the DMV is getting into banking.
How many cards are you carrying around, anyway?
Just credit cards, or in general?
In general, I have a bus pass, credit card, debit card, driver's license, student ID, and some other stuff that I actually have no need for (but isn't harmful to have either). That's 5 cards that I have a use for on a regular basis. I suppose I could cut off one of the credit or debit cards, but I like using the credit card for almost all purchases (I pay off the balance in full each month; it just lets me hold the money a little longer and builds credit) and I need something I can get cash with. Dropping a couple of those cards would be pretty nice.
alcohol, tobacco, skin mags, R-rated movies, and M-rated games (don't you just love how those last two are lumped in with the first three?)
I'm not sure how skin mags fall into a separate category from R movies and M games. I could see you saying "don't you just love how those last *three* are lumped in with the first two...
Yeah, government and business working in collusion, more so than usual.
How is the government colluding in this? Near as I can tell, it's just private enterprise.
I wonder what something like this will do, when the key to free stuff now, and debt later, is right in your wallet at all times, and you have to carry it around.
Um, that's what most people do already.
Besides, methinks you're getting debit and credit cards confused. (Not that credit cards will probably be right on the heels.)
What's the difference? For most people that'd mean stealing your wallet - they'll get both pieces of information anyway.
This is exactly right.
Not quite sure why this is an issue.
Wait, what does that have to do with science?
I still will bet big money that Child of Vista will run 32 bit code just fine.
Oh, I'm sure too. I would say there's probably another decade and a half or two of support for 32-bit applications.
By my understanding, Vista has already dropped support for 16 bit code.
Just to clarify, this should say x64 Vista. 32-bit builds of Vista still come with WOW16.
The child of Vista will "require" a 64-Bit CPU to boot but you can bet your bottom dollar that it will run 32 and even 16 bit code.
By my understanding, Vista has already dropped support for 16 bit code.
In Windows NT (generic term for NT, 2K, XP, Vista...), programs don't make direct system calls. In fact, the system call interface (called the Native API) is somewhat undocumented and completely unsupported. In fact, the Windows build process automatically generates system call numbers during each build. Instead, NT has a notion of subsystems that provide a "view" of the system calls through a different API. The one that 99% (this statistic from a study from Out Of My Ass, Inc.) of Windows programs use is called the Windows subsystem (previously the Win32 subsystem) because it provides Windows API calls (previously the Win32 API). In other words, the Windows subsystem translates Win32 API functions to NT system calls. For instance, CreateFile behind the scenes calls the NT function NtCreateFile. While named similarly, they have different arguments. In general, Win32 API functions may make no system calls or multiple system calls, and also do some other bookkeeping stuff.
(If you remember during the MS antitrust trial people were saying that Office had an unfair advantage because MS was using undocumented APIs -- I'm pretty sure that this is what they were talking about. And from what I hear, when the Windows team found out that the Office team was using their native API, they were none to happy.)
Anyway, the point of this is as follows. When you run a 16-bit program in the 32-bit version of NT, it does NOT run in the Windows subsystem. It runs in a different subsystem made for running 16-bit programs. (It's called Windows on Windows 16, or WOW16. If you look in your processes list and you run a 16-bit program, you'll see it there as wowexec.exe.) The same thing is true if you run 32-bit programs in 64-bit Windows: it runs in a separate subsystem, WOW64. (Don't ask me why it's not WOW32...)
Now, WOW16 is not shipped with 64-bit versions of Windows. Thus your support for DOS and Win3.1 applications (unless they use Win32s... wow, that's something I didn't think I'd say again) has *already* been dropped from 64-bit versions.
I suppose it's possible they'll add it back... but I doubt it.
Unfortuneately in the post 11/9/2001 world, our leaders seem to have forgotten that lesson...
They haven't forgotten it; it's in their interest to ignore it.
The people who picket funerals are the "Westboro Baptist Church", headed by Fred Phelps. He is beyond the pale, and should no more be associated with the American religious right in general than Stalin should be associated with socialist politics. ...
Yes, Falwell said some stupid things--things that frustrated, embarrassed, and angered me as a theologically-conservative Christian. But please, do not associate Phelps' actions with anyone other than Fred Phelps.
Can I associate Phelps's actions with, I dunno, Satan? I think that's reasonable. At least to Phelps.
Actually, there's a reason behind the playpen balls (not pens). It's a reference to the strip.
He or she is obviously more interested in personal wealth than the invention and than those in need of the invention. In the first scenario, if the invention did eventually get out, everyone could benefit from it, regardless of their wealth. The world would be a better place. In the second scenario, the inventor makes a killing, and the cure is held hostage, and only those willing to pay up will get the cure. The world is a better place for the inventor and the rich.
The first one is nice, but what if the alternative is NO cure? Then which is better, no cure, or greedy bastard's cure?
Thanks for that response. I'd give some benchmarks of my own a shot except... I have an Athlon XP. ;-)
For really bright lights, a small square of aluminum foil works well, and is absolutely opaque.
Foil also works great as a blackout curtain. Made one out of foil and duct tape while I was in northern Norway with 24 hour sun for a month. Worked wonders.
Not sure why I typed "make" in capitals...
MAKE -j6.
Mmmmmmmm....
(-j6 instead of -j4 in an effort to counter I/O latencies... Actually that'd be an interesting benchmark; figure out what the optimum level of parallelism is. Too little and processors will be idle, too much and context switches would become an issue.)
I looked at files in explorer. I changed the name of a file from, say, FOO.html to foo.html.
Explorer told me it changed the name. It didn't.
Opening a command window and typing dir showed the *actual* name of the file.
move FOO.html foo.html *did* change the name.
That is badly broken behavior.
Hmm, what you describe is broken. Any chance you can figure out how to reproduce this so I can see if I can figure out what's going on? Not that I'd be able to do anything about it of course, I'm just curious.
None of your examples are similar at all.
Why aren't they?
(Well, at least why aren't they similar to the difference between case sensitivity and insensitivity; I can see why they could be considered different from the problem you are describing.)
Any thing that causes your computer to flat out lie to you is not worth having.
Hmm, that doesn't seem like a good argument to me.
First, whose to say that the problem you name isn't caused by Unix lying about whether "foo.html" and "Foo.html" are different files?
Second, your computer lies to you all the time. If you run a program, it's written in x86 instructions. But really you're executing microcode on uops. Should Intel go back and revamp their chips so that they are executing straight IA-32 without microcode?
Or open a calculator and type 3 + 4. Hey wait, the computer's lying to you! It can't actually add 3 and 4, it has to add 0000 0011 and 0000 1000 (or the word, dword, or qword version, or the floating point version). Should we say that those numbers are a lie, because they are actually stored in binary?
Or this text you're reading. It's actually stored and transmitted as ASCII numbers. Is it a lie to present a different view to you for ease of use?
Heck, the whole representation of binary in 0s and 1s is a lie. It's really just changes between voltage levels.
I think that we should have an interface to the computer where the output is a voltmeter and the input is you tapping the poles of a battery with a wire.
Where should the lies end? Why should they end with a case sensitive file system?
If you've got malicious code running that's able to create files with arbitrary names on your local file system, and perhaps even enable case sensitivity, you've got bigger problems than the names that code decides to use. It sounds to me like one of the typical examples of complaining that a machine that's already been compromised by a virus can be attacked by it: well, naturally.
Eh, but this is a common assumption, that the attacker has access to the computer. It's not so outlandish, and is one of the common security models.
It's not so much that a machine that's compromised can be attacked, it's that this feature raises the bar* on what the detector has to do to find it. Virus writers seem to be a little less disinclined to use undocumented/unsupported APIs to do their work than people who write security software. (Though the latter group is more inclined to use them than just about any other software I know of.)
* In XP and older, this feature isn't alone; streams cause the same problem. In Server 2003, Windows API functions FindFirstStream and FindNextStream were added which allow programs to enumerate alternate streams. This means that in 2K3 and Vista, this case sensitivity thing is the only reason I know of why a virus scanner would have to drop to the Native API.
To some extent I'm tempted to agree with your point about matching, i.e. that 'FOO' should match 'FOO', whether or not 'foo' also exists. However, you then run into a situation where the matching isn't actually case-insensitive. This means that two calls which are documented to have the same effect, e.g. open("foo") and open("FOO"), will actually have different results, so you've just exchanged one problem for another. On the whole, I think I'd actually lean towards having the same file always returned, if case insensitivity is enabled.
It's a good argument and I guess some usability testing would be in order. (For instance, do programs depend on opening files with differing case to end up the same file, and if they do, does always returning the same one fix it?)
I tend to suspect the tradeoff would go the other way, but then again, I haven't done the testing.