FreeDOS is nice (though about 20 years too late... isn't that always the way?). How about ELKS though? It's a 16-bit version of Linux, more or less. The project doesn't seem very active at the moment.
If you have access to a Unix box somewhere on the net, set up an http proxy server on it and make an ssh tunnel from your machine to it with forwarding of port 3128 or 8080 or whatever the proxy runs on. Then do all your web browsing through that ssh tunnel. This is usually faster over a modem link because you don't have the latency of doing DNS lookups and opening new TCP connections locally.
If the proxy server at the other end is something like RabbIT that can compress images and web pages, so much the better. If you run WWWOFFLE locally to do agressive caching of pages (and allow offline browsing), better still. For added blazing speed use dillo as your web browser (though I must admit I mostly use Firefox nowadays).
Finally note that you don't need loband.org for Slashdot - just enable 'light mode' in your preferences.
This is why a secure attention sequence is a good idea. A magic keystroke that cannot be intercepted by user programs and which users get used to typing before entering their password. If sudo asked you: press Ctrl-Alt-Del to authenticate yourself, then a keylogger installed with a user account wouldn't be able to get the root password. This is one thing Windows gets right (from its VMS heritage).
If you get more usability, security, performance, or what have you, out of Linux than you do out of MacOS X, then it does not matter whether or not you have already paid for MacOS X.
It depends how bothered you are by the possibility your code could be distributed under some unsuitable licence. Many developers write BSD-licensed code and allow redistribution of it under almost any conditions, even the most restrictive proprietary licences. Myself I think the GPL is a useful tool to encourage the development of more free software so I licence most of what I write under the GPL; but if a new 'send money to RMS' version of the GPL came out I'd just sigh and probably relicence my code under BSD, if there was no longer a consensus that the GPL was a useful licence.
On the other hand, having large amounts of code that is GPL v2 only could be a real obstacle if GPL v3 comes out and people start adopting it. It is much more likely that future versions of the GPL will be an improvement and address problems facing free software (eg software patents) than the imaginary 'RMS goes to the dark side' scenario.
So I think you should weigh up the probabilities fairly and decide which is the bigger risk to developers: allowing distribution under newer GPLs, or not allowing it. If you still decide that you don't like the idea of the FSF adding new choices to the copying conditions for your program, seriously consider using the new-style BSD licence or MIT licence - then at least you have an explicitly level playing field.
Now, why can't the last three commands be done using a pipe? (disregarding considerations of buffering - though I think there is some filter you can put in a pipeline to provide that)
Now steady on. I don't think RMS has ever said that the GPL should force the release of code that is used in a 'public' way like yahoo.com but not otherwise distributed. All we've seen is interviews with other FSF folk like Eben Moglen who have said that this issue among others is being considered, and that there will be an extra long consultation period before version 3 is released.
In fact, RMS has explicitly said that a licence that doesn't allow private versions of software is non-free. The original APSL required you to publish any changes you made to the code - much stricter than the GPL which says only that what you do release, you must release under the GPL. RMS quite rightly said that this makes the original APSL non-free. You might like to read what RMS actually says before deciding that he disagrees with you.
Finally, isn't it most sensible to allow GPL version 2 or any later version *at your option*, and let the users decide whether they wish to move to the new version of the GPL when it's announced? If the new version is unreasonable, people will be free to stick with v2.
You are allowing the user to choose version 2 or later *at their option*. So RMS can release a new GPL that is more liberal, but he can't change the licensing of your code to something more restrictive. Or at least if he did go nuts and release GPLv99 with all sorts of crazy clauses, everyone could ignore it and keep using version 2.
So I think it makes the most sense in the long run not to get too paranoid and to license your code under version 2 or later - at the user's choice.
Yes, but most of the features of C++ were expressly designed to avoid causing bloat that is swept under the rug. Stroustrup's motto was 'not one extra cycle and not one extra byte' and for the most part C++ achieves this. Virtual inheritance does introduce an extra runtime lookup on each member function call, but this is no worse than what you'd incur if you emulated the same thing in C with a struct full of function pointers (as the kernel does).
However, advocating 1985-era C++ in the Linux kernel is a bit pointless. It may not have any extra overhead compared to C, but neither does it give you a great deal apart from syntactic convenience. When people ask for C++, they usually want exceptions, virtual functions, RTTI and even templates - and I can understand why the kernel wouldn't want those because they really can cause bloat (and dragging in parts of the C++ ABI and standard library).
I think I still agree with Stroustrup that there is no good reason to start writing a program in C rather than C++, and if you don't want the extra overhead associated with certain C++ features then don't use those features. But this isn't necessarily an argument that existing C code should have C++ bits bolted onto it.
In some sense, C++ asks the wrong question entirely of objects. Something wants a particular object method, so it checks the type of the object and based on that infers the presence of the method.
Not quite. With template programming you can quite easily write code that works with any type that has a foo() member function. They do not need to inherit from a common base class. Consider the STL's algorithms such as sort(): they work with any iterators, and an iterator is simply a type defining the * and ++ operators. There is no 'iterator' base class.
So you have both ways of checking for a method: both by inheritance and by just looking for one with the same name and a compatible signature. This choice is both a blessing and a curse. One obvious difference with Python is that if the lookup fails, the error is caught at compile time. This too has a good and bad side. (I like compile time checking but dislike the syntactic hoops C++ sometimes makes you jump through.)
It's interesting you mention Linux: my feeling glancing at kernel code snippets in LWN is that they go to a lot of trouble to reimplement in C things that C++ provides with a lot less fuss. After all, C++ was created by a C programmer. What are the kernel folk doing with C that C++ doesn't provide?
I agree with your comments about C++. Too much syntax, too much thinking about language weirdness. But it's unfair to characterize C++'s strong typing as being all about ints, floats and chars and not including 'real world' types.
I'm not recommending you leave Python - just be aware of what's out there and don't assume that strong typing means 'awkward like C++'. There are many strongly typed languages where the type checker is a joy to use and really makes your life easier. (especially with type inference)
Security should not depend on keeping the algorithm secret.
Absolutely. If you are hoping that the attacker will not know the algorithm you use, then that is security through obscurity.
Now, take the case of displaying a secret number on the user's PC. Remember that we are talking about the situation where the user's PC has been Trojaned and is running hostile software. My point is that the hostile software can easily intercept the number that's being displayed. If it is displayed on the PC, then a program which has control of that PC can find out the number.
Ah, you say, but why not display the number as an image or a 3d animation of some digits? It's this step that I would call security through obscurity.
If you know that some malicious program is running on the user's PC and you just hope that it won't find out the mechanism you have used to turn the secret number into an image or animation, then you are relying on the attacker not knowing the algorithm you're using.
In reality any mechanism you used to display the number on the user's PC - whether you sent it as an image, an animation, a sound file, a computer-generated riddle - could be discovered by the malware authors and with a little effort reversed. As you say, it would be an impressive feat of programming to read some obscured OCR digits, but it's not impossible and certainly not in the same league as cracking a secure encryption algorithm.
If you did use some program to make an image with obscured graphic digits, would you be confident enough to publish the code to that program so that attackers could test it out and use it to help refine their OCR programs? (I expect an attacker would set up an automated test rig running your generator thousands of times and tweaking the decoder to see which settings give best results.) If you're not sure you could publish the code, you're relying on security through obscurity.
If you believe you could safely publish the source code for your image generator, then we simply disagree on how hard it would be to write an OCR program for it. I think it wouldn't be _that_ hard, especially considering the financial rewards.
The important part is that the bank calls you, and you must enter the code via. your phone -- a completely different network.
Yes this is the important part, and that's why I suggested just keeping this part and requring the user to type in today's date in the phone. Never mind the business of trying to send a secret code to the user's PC, because that will not be secret anyway (if the PC is running malware).
A custom app in your phone, communicating with the bank via. a compromised PC, can still manage to correctly verify your identity.
Yes. Then you have a secure communication between your phone and the bank. Effectively you have telephone banking. You might as well cut out the PC altogether. (You do still have the problem of users installing trojan software on their mobile phones...)
The question we're really dancing around here is can the bank "trust" the code on the user's PC.
The specific point I wanted to make was that if an attacker gets control of the user's PC, nothing you do will make that PC secure for online banking. You can only rely on the attacker not being that intelligent, which is a dangerous assumption to make.
Given that if a trojan program gets installed the game is lost, how do we prevent users from installing such software? Booting off a special CD is a good first step. Your activation scheme is a good idea; the difficulty is with social engineering like 'the activation phone number for this release has changed'... Similarly, if you have a return envelope for the old CD who is going to check that the bank's address on it is the same as last time?
I think the difference is that if you are moving a file from one directory to another, you can see the two directories' contents in two different windows. Then you can drag the files across and see them disappear from one directory and appear in the other. An interface with a tree down the LHS lets you view the source directory but there is no space on screen showing the destination directory and what changes there.
Or to put it another way, it is good to have one area of the screen for directory A and a separate area for B. They are two different places on disk and two different places on screen. Whereas a File-Manager type interface has one right-hand panel which changes to view different directories in turn.
The spatial interface makes a lot more sense when you can save files by dragging them from the application into the filer window. It's such a shame that none of the popular Unix desktop environments have a decent, intuitive file saving mechanism. They're still in the world of popping up a mini single-window file manager and getting the user to click through that to the directory wanted. I would prefer to have a window open for the dir I'm working in and drag files to and from that in all applications.
My point though was that I want to deal with "types" that are not computer types. I want a type that has a URL and id, or I want a type that is callable, or a type that is iterable and supports containment checking.
Have a look at Haskell, or ML, or even C++. Essentially any strongly typed language that lets you define your own interfaces.
One of the things I like about the python interface stuff is I don't have to have things inherit from a base class in order to follow that interface. The interface and the inheritance are separate so I can have something that says it follows a list interface but does not need to inherit from list.
This is true in C++ too, once you start getting into generic programming with templates. (For example the different kinds of iterator do not inherit from any common base class.) But the syntax is nasty. In languages like Haskell there is also no need to inherit from a common base class to implement a particular interface.
I liked the Filer on RISC OS: it uses a spatial model but you can double-click with the right button instead of the left to open a folder while closing the old window at the same time.
I don't think anyone can fully explain _why_ they prefer spatial or browser model; it's just a matter of taste and what you're used to. I like the idea of two directories being physically different places and you can drag files from 'here' to 'there'. This doesn't mean that others are wrong to prefer a browser interface. The only objective comparison is to do a study of some ordinary users and find which interface is easier to learn and which gives a better understanding (that is, knowledge which you can then use to help you use other applications).
Displaying a secret number as a graphic is an attempt at security through obscurity. You hope that the trojan won't be clever enough to work out the number from what's sent by the server, although a human clearly can. This approach makes some sense for things like avoiding comment spam, where the stakes are not that high. It really isn't suitable for online banking unless you have great confidence that no programmer could write something to OCR your graphic or read your spinning digits or solve your jigsaw puzzle or whatever.
The only point I'm making is that (in practice as well as in theory) it's impossible to keep any shared secret between the bank and the user if the way you communicate it is _only_ through a compromised PC. If the PC displays something so that the user can read it, then the trojan can read it too. Maybe not trivially but certainly with a little programming effort.
You suggest doing a challenge-response to prove that the original CD image is available. Then if the genuine CD were filled to bursting, there would be no room to put malicious code on the disc and still have the whole original image to answer the bank's checksum queries. I think a malware author could almost certainly squeeze out the few extra kilobytes needed by using a better compression program on the 'good' copy of the software, but even if we assume that it's quite impossible to fit anything more on the CD, your challenge still only proves that the contents of the 'good' CD are available, not that they're running. The trojan could send network requests to a third server run by the attacker, which would compute the answers to the challenges posed by the bank.
I do not think that there is any way you can compensate for the user's PC running trojaned software. If someone else is in control of the computer that the user is typing at, that's it, game over.
Yes, why can't they list them by numeric country code as used for telephone calls, where the USA is 1? In fact we should just rename all countries to numbers instead, for example Nigeria would be 234 (not 419, sadly).
If a number is displayed in the browser window then it can be read by the trojan software. Now the authentication code would be different each time, so the trojan couldn't do much with this number. But still, the fact that the trojan can't read your mobile phone keystrokes is irrelevant if you're typing in something that is plainly displayed on screen anyway. You'd get the same level of security by asking the customer to type today's date into the mobile phone.
I do agree that having the bank call your phone when you log in provides an extra level of security - nobody can go behind your back and start using your account while you're asleep.
I still think, however, that if the PC is trojaned then the game is lost. For example if you log in successfully and then ask to transfer $100 to account X, the trojan can alter the outgoing message to send the money to account Y instead. And so on. You could get round this by having the bank ring the customer's phone to confirm the details of every transaction, but then you have telephone banking not Internet banking.
On having to give up the freedom to run arbitrary software in order to guarantee no malware - I didn't say that giving up your freedom is a good thing, just that it seems to be the only 100% answer to the problem. If every user can run whatever software they choose, then inevitably there will be some so stupid that they download and install a dancing elephants program which gives an attacker access to their bank account.
(As it happens I agree with you that it's better to keep freedom even at the cost of some loss of security.)
I don't understand how your solution defends against someone sending out a fake banking CD that has trojans on it. Such a CD could still connect to the bank's server as normal and do everything the real one would, while at the same time logging the user's keystrokes and sending them via UDP packets to Kazakhstan or Kentucky or wherever.
One answer to the problem of fake CDs would be to digitally sign each CD - then to verify the authenticity of a new version, you would boot the previous one (perhaps with network cable unplugged), insert the new CD when prompted and it'd check the signature. But it's a tough job persuading consumers they need to do this rather than just throwing away the old disc and booting the new one.
Maybe you could try to make sure they follow this process by making each CD need an authentication code to boot, and the only way you find out the correct authentication code for the replacement CD is by running a program (from the old CD) which checks the signature. So the authentication code would not be a real security measure but just a hoop users must jump through to make sure they've checked each CD they receive.
That still doesn't defend against an attacker sending out a new CD together with a letter saying 'For this release, we have changed the upgrade procedure - there is no longer any need to generate an authentication code [ie, check the signature]' or sneakier still, 'The authentication code for this version is 12345'.
It's a hard problem to persuade people not to run code on their computers without checking where it came from. And this in about the simplest possible scenario of a single self-contained disc. How much harder if the user is running Windows!
Maybe Trusted Computing could help with this - don't boot any OS unless it is signed by the bank - but so would creating a boot floppy (which checks a signature and boots the CD) and supergluing it into the floppy drive so it can't be removed. Essentially, any 100% solution to the malware problem must involve consumers giving up the freedom to run software of their choice...
Actually I think mailing out new CDs is far more likely to work than persuading users to keep their own systems (especially Windows boxes) up to date.
(You could in principle install a Linux system on each user's own hard disk and push out updates to it, but giving them a new CD has far less to go wrong.)
I rather miss the days when performing an operating system upgrade was as simple as opening the computer and putting in some new ROM chips; putting in a new CD and rebooting is getting back towards that level of friendliness.
'When all you have is a hammer, everything looks like a nail.'
That's what I thought when reading Jeffrey Friedl's book on regexps and it looks like this one is the same.
Besides, why a book? Speaking from the perspective of a Perl programmer it makes much more sense to create libraries of real code. I guess if you're working in config files, or sed, or other tools that aren't full programming languages, then typing in things from a book could be useful.
Slashdot Mirror
FreeDOS is nice (though about 20 years too late... isn't that always the way?). How about ELKS though? It's a 16-bit version of Linux, more or less. The project doesn't seem very active at the moment.
Of course, Minix is now free software...
If you have access to a Unix box somewhere on the net, set up an http proxy server on it and make an ssh tunnel from your machine to it with forwarding of port 3128 or 8080 or whatever the proxy runs on. Then do all your web browsing through that ssh tunnel. This is usually faster over a modem link because you don't have the latency of doing DNS lookups and opening new TCP connections locally.
If the proxy server at the other end is something like RabbIT that can compress images and web pages, so much the better. If you run WWWOFFLE locally to do agressive caching of pages (and allow offline browsing), better still. For added blazing speed use dillo as your web browser (though I must admit I mostly use Firefox nowadays).
Finally note that you don't need loband.org for Slashdot - just enable 'light mode' in your preferences.
What's the plural of 'Virus'?
Even if you don't agree with Moore's Law, there's no denying its contributions to computing culture. Truly an American icon.
This is why a secure attention sequence is a good idea. A magic keystroke that cannot be intercepted by user programs and which users get used to typing before entering their password. If sudo asked you: press Ctrl-Alt-Del to authenticate yourself, then a keylogger installed with a user account wouldn't be able to get the root password. This is one thing Windows gets right (from its VMS heritage).
Interesting signature. But why not:
Liberté, egalité, fraternité: pick any two.
It depends how bothered you are by the possibility your code could be distributed under some unsuitable licence. Many developers write BSD-licensed code and allow redistribution of it under almost any conditions, even the most restrictive proprietary licences. Myself I think the GPL is a useful tool to encourage the development of more free software so I licence most of what I write under the GPL; but if a new 'send money to RMS' version of the GPL came out I'd just sigh and probably relicence my code under BSD, if there was no longer a consensus that the GPL was a useful licence.
On the other hand, having large amounts of code that is GPL v2 only could be a real obstacle if GPL v3 comes out and people start adopting it. It is much more likely that future versions of the GPL will be an improvement and address problems facing free software (eg software patents) than the imaginary 'RMS goes to the dark side' scenario.
So I think you should weigh up the probabilities fairly and decide which is the bigger risk to developers: allowing distribution under newer GPLs, or not allowing it. If you still decide that you don't like the idea of the FSF adding new choices to the copying conditions for your program, seriously consider using the new-style BSD licence or MIT licence - then at least you have an explicitly level playing field.
Now, why can't the last three commands be done using a pipe? (disregarding considerations of buffering - though I think there is some filter you can put in a pipeline to provide that)
Now steady on. I don't think RMS has ever said that the GPL should force the release of code that is used in a 'public' way like yahoo.com but not otherwise distributed. All we've seen is interviews with other FSF folk like Eben Moglen who have said that this issue among others is being considered, and that there will be an extra long consultation period before version 3 is released.
In fact, RMS has explicitly said that a licence that doesn't allow private versions of software is non-free. The original APSL required you to publish any changes you made to the code - much stricter than the GPL which says only that what you do release, you must release under the GPL. RMS quite rightly said that this makes the original APSL non-free. You might like to read what RMS actually says before deciding that he disagrees with you.
Finally, isn't it most sensible to allow GPL version 2 or any later version *at your option*, and let the users decide whether they wish to move to the new version of the GPL when it's announced? If the new version is unreasonable, people will be free to stick with v2.
You are allowing the user to choose version 2 or later *at their option*. So RMS can release a new GPL that is more liberal, but he can't change the licensing of your code to something more restrictive. Or at least if he did go nuts and release GPLv99 with all sorts of crazy clauses, everyone could ignore it and keep using version 2.
So I think it makes the most sense in the long run not to get too paranoid and to license your code under version 2 or later - at the user's choice.
Yes, but most of the features of C++ were expressly designed to avoid causing bloat that is swept under the rug. Stroustrup's motto was 'not one extra cycle and not one extra byte' and for the most part C++ achieves this. Virtual inheritance does introduce an extra runtime lookup on each member function call, but this is no worse than what you'd incur if you emulated the same thing in C with a struct full of function pointers (as the kernel does).
However, advocating 1985-era C++ in the Linux kernel is a bit pointless. It may not have any extra overhead compared to C, but neither does it give you a great deal apart from syntactic convenience. When people ask for C++, they usually want exceptions, virtual functions, RTTI and even templates - and I can understand why the kernel wouldn't want those because they really can cause bloat (and dragging in parts of the C++ ABI and standard library).
I think I still agree with Stroustrup that there is no good reason to start writing a program in C rather than C++, and if you don't want the extra overhead associated with certain C++ features then don't use those features. But this isn't necessarily an argument that existing C code should have C++ bits bolted onto it.
So you have both ways of checking for a method: both by inheritance and by just looking for one with the same name and a compatible signature. This choice is both a blessing and a curse. One obvious difference with Python is that if the lookup fails, the error is caught at compile time. This too has a good and bad side. (I like compile time checking but dislike the syntactic hoops C++ sometimes makes you jump through.)
It's interesting you mention Linux: my feeling glancing at kernel code snippets in LWN is that they go to a lot of trouble to reimplement in C things that C++ provides with a lot less fuss. After all, C++ was created by a C programmer. What are the kernel folk doing with C that C++ doesn't provide?
I agree with your comments about C++. Too much syntax, too much thinking about language weirdness. But it's unfair to characterize C++'s strong typing as being all about ints, floats and chars and not including 'real world' types.
I'm not recommending you leave Python - just be aware of what's out there and don't assume that strong typing means 'awkward like C++'. There are many strongly typed languages where the type checker is a joy to use and really makes your life easier. (especially with type inference)
Now, take the case of displaying a secret number on the user's PC. Remember that we are talking about the situation where the user's PC has been Trojaned and is running hostile software. My point is that the hostile software can easily intercept the number that's being displayed. If it is displayed on the PC, then a program which has control of that PC can find out the number.
Ah, you say, but why not display the number as an image or a 3d animation of some digits? It's this step that I would call security through obscurity.
If you know that some malicious program is running on the user's PC and you just hope that it won't find out the mechanism you have used to turn the secret number into an image or animation, then you are relying on the attacker not knowing the algorithm you're using.
In reality any mechanism you used to display the number on the user's PC - whether you sent it as an image, an animation, a sound file, a computer-generated riddle - could be discovered by the malware authors and with a little effort reversed. As you say, it would be an impressive feat of programming to read some obscured OCR digits, but it's not impossible and certainly not in the same league as cracking a secure encryption algorithm.
If you did use some program to make an image with obscured graphic digits, would you be confident enough to publish the code to that program so that attackers could test it out and use it to help refine their OCR programs? (I expect an attacker would set up an automated test rig running your generator thousands of times and tweaking the decoder to see which settings give best results.) If you're not sure you could publish the code, you're relying on security through obscurity.
If you believe you could safely publish the source code for your image generator, then we simply disagree on how hard it would be to write an OCR program for it. I think it wouldn't be _that_ hard, especially considering the financial rewards.Yes this is the important part, and that's why I suggested just keeping this part and requring the user to type in today's date in the phone. Never mind the business of trying to send a secret code to the user's PC, because that will not be secret anyway (if the PC is running malware).Yes. Then you have a secure communication between your phone and the bank. Effectively you have telephone banking. You might as well cut out the PC altogether. (You do still have the problem of users installing trojan software on their mobile phones...)The specific point I wanted to make was that if an attacker gets control of the user's PC, nothing you do will make that PC secure for online banking. You can only rely on the attacker not being that intelligent, which is a dangerous assumption to make.
Given that if a trojan program gets installed the game is lost, how do we prevent users from installing such software? Booting off a special CD is a good first step. Your activation scheme is a good idea; the difficulty is with social engineering like 'the activation phone number for this release has changed'... Similarly, if you have a return envelope for the old CD who is going to check that the bank's address on it is the same as last time?
I think the difference is that if you are moving a file from one directory to another, you can see the two directories' contents in two different windows. Then you can drag the files across and see them disappear from one directory and appear in the other. An interface with a tree down the LHS lets you view the source directory but there is no space on screen showing the destination directory and what changes there.
Or to put it another way, it is good to have one area of the screen for directory A and a separate area for B. They are two different places on disk and two different places on screen. Whereas a File-Manager type interface has one right-hand panel which changes to view different directories in turn.
The spatial interface makes a lot more sense when you can save files by dragging them from the application into the filer window. It's such a shame that none of the popular Unix desktop environments have a decent, intuitive file saving mechanism. They're still in the world of popping up a mini single-window file manager and getting the user to click through that to the directory wanted. I would prefer to have a window open for the dir I'm working in and drag files to and from that in all applications.
This is true in C++ too, once you start getting into generic programming with templates. (For example the different kinds of iterator do not inherit from any common base class.) But the syntax is nasty. In languages like Haskell there is also no need to inherit from a common base class to implement a particular interface.
I liked the Filer on RISC OS: it uses a spatial model but you can double-click with the right button instead of the left to open a folder while closing the old window at the same time.
I don't think anyone can fully explain _why_ they prefer spatial or browser model; it's just a matter of taste and what you're used to. I like the idea of two directories being physically different places and you can drag files from 'here' to 'there'. This doesn't mean that others are wrong to prefer a browser interface. The only objective comparison is to do a study of some ordinary users and find which interface is easier to learn and which gives a better understanding (that is, knowledge which you can then use to help you use other applications).
Displaying a secret number as a graphic is an attempt at security through obscurity. You hope that the trojan won't be clever enough to work out the number from what's sent by the server, although a human clearly can. This approach makes some sense for things like avoiding comment spam, where the stakes are not that high. It really isn't suitable for online banking unless you have great confidence that no programmer could write something to OCR your graphic or read your spinning digits or solve your jigsaw puzzle or whatever.
The only point I'm making is that (in practice as well as in theory) it's impossible to keep any shared secret between the bank and the user if the way you communicate it is _only_ through a compromised PC. If the PC displays something so that the user can read it, then the trojan can read it too. Maybe not trivially but certainly with a little programming effort.
You suggest doing a challenge-response to prove that the original CD image is available. Then if the genuine CD were filled to bursting, there would be no room to put malicious code on the disc and still have the whole original image to answer the bank's checksum queries. I think a malware author could almost certainly squeeze out the few extra kilobytes needed by using a better compression program on the 'good' copy of the software, but even if we assume that it's quite impossible to fit anything more on the CD, your challenge still only proves that the contents of the 'good' CD are available, not that they're running. The trojan could send network requests to a third server run by the attacker, which would compute the answers to the challenges posed by the bank.
I do not think that there is any way you can compensate for the user's PC running trojaned software. If someone else is in control of the computer that the user is typing at, that's it, game over.
Yes, why can't they list them by numeric country code as used for telephone calls, where the USA is 1? In fact we should just rename all countries to numbers instead, for example Nigeria would be 234 (not 419, sadly).
Where does Curzon Dax fit in that list?
If a number is displayed in the browser window then it can be read by the trojan software. Now the authentication code would be different each time, so the trojan couldn't do much with this number. But still, the fact that the trojan can't read your mobile phone keystrokes is irrelevant if you're typing in something that is plainly displayed on screen anyway. You'd get the same level of security by asking the customer to type today's date into the mobile phone.
I do agree that having the bank call your phone when you log in provides an extra level of security - nobody can go behind your back and start using your account while you're asleep.
I still think, however, that if the PC is trojaned then the game is lost. For example if you log in successfully and then ask to transfer $100 to account X, the trojan can alter the outgoing message to send the money to account Y instead. And so on. You could get round this by having the bank ring the customer's phone to confirm the details of every transaction, but then you have telephone banking not Internet banking.
On having to give up the freedom to run arbitrary software in order to guarantee no malware - I didn't say that giving up your freedom is a good thing, just that it seems to be the only 100% answer to the problem. If every user can run whatever software they choose, then inevitably there will be some so stupid that they download and install a dancing elephants program which gives an attacker access to their bank account.
(As it happens I agree with you that it's better to keep freedom even at the cost of some loss of security.)
I don't understand how your solution defends against someone sending out a fake banking CD that has trojans on it. Such a CD could still connect to the bank's server as normal and do everything the real one would, while at the same time logging the user's keystrokes and sending them via UDP packets to Kazakhstan or Kentucky or wherever.
One answer to the problem of fake CDs would be to digitally sign each CD - then to verify the authenticity of a new version, you would boot the previous one (perhaps with network cable unplugged), insert the new CD when prompted and it'd check the signature. But it's a tough job persuading consumers they need to do this rather than just throwing away the old disc and booting the new one.
Maybe you could try to make sure they follow this process by making each CD need an authentication code to boot, and the only way you find out the correct authentication code for the replacement CD is by running a program (from the old CD) which checks the signature. So the authentication code would not be a real security measure but just a hoop users must jump through to make sure they've checked each CD they receive.
That still doesn't defend against an attacker sending out a new CD together with a letter saying 'For this release, we have changed the upgrade procedure - there is no longer any need to generate an authentication code [ie, check the signature]' or sneakier still, 'The authentication code for this version is 12345'.
It's a hard problem to persuade people not to run code on their computers without checking where it came from. And this in about the simplest possible scenario of a single self-contained disc. How much harder if the user is running Windows!
Maybe Trusted Computing could help with this - don't boot any OS unless it is signed by the bank - but so would creating a boot floppy (which checks a signature and boots the CD) and supergluing it into the floppy drive so it can't be removed. Essentially, any 100% solution to the malware problem must involve consumers giving up the freedom to run software of their choice...
Actually I think mailing out new CDs is far more likely to work than persuading users to keep their own systems (especially Windows boxes) up to date.
(You could in principle install a Linux system on each user's own hard disk and push out updates to it, but giving them a new CD has far less to go wrong.)
I rather miss the days when performing an operating system upgrade was as simple as opening the computer and putting in some new ROM chips; putting in a new CD and rebooting is getting back towards that level of friendliness.
'When all you have is a hammer, everything looks like a nail.'
That's what I thought when reading Jeffrey Friedl's book on regexps and it looks like this one is the same.
Besides, why a book? Speaking from the perspective of a Perl programmer it makes much more sense to create libraries of real code. I guess if you're working in config files, or sed, or other tools that aren't full programming languages, then typing in things from a book could be useful.