Here's one to get you started: "I'm working from home today about I don't want replies to my business email sent to my home account."
Three solutions: 1) Use your work's SMTP server 2) Change your reply-to address 3) Add your ISP's SMTP server to the "allowed to send email for this domain" list at work
This would also cause serious problems for mobile users -- if I'm on the road, who knows what ISP I'll be connecting to. However, I probably want my From: address to stay the same no matter where I'm connected.
It doesn't matter what ISP you're connecting to on the road -- you should still be able to use your home ISP's SMTP server.
Re:Travelling Mailman problem's solution's problem
on
Spoofed From: Prevention
·
· Score: 2, Informative
Traveling mailman problem:
In this situation, wouldn't you just connect to the ISP's SMTP server and send the email? This system is designed to authenticate SMTP servers, not people connecting to them.
Any mailserver internal to a network
If your internal server tries to send email from reported to be from cox.net (or whatever their domain is) then yes, you'll have a problem. Don't do that.
However, if you own mydomain.com, and have your SPF server report it's ip as an authoritative SMTP server for sending mail from mydomain.com, you don't have any problems.
It makes filtering spam a lot easier. For one thing, you no longer have spoofed email addresses to deal with. Now, email that claims to come from "aol.com" will really come from aol.com, instead of some spam server.
Secondly, in order to register a domain you need to provide some sort of cc information which would imply that there would be a way to track down spammers (assuming they didn't use stolen cc's, and I wouldn't put that past 'em -- but then they're commiting an actual crime and this kind of thing is much easier to put people in jail for than the current crimes they commit).
Thirdly, it adds costs to the spammer's bottomline. Reducing "profitablity" from spamming == good way to reduce spamming; if it cost them a new domain for every 10000 spams they send out, it'd cost them $800 to send one million spam emails. Not to mention the time it takes for domain info to propigate after registering it, etc (spams will fail to get through until the dns info exists).
As far as registering the victim hostname with the SFP server, that would imply that you would have access to the SFP server. I doubt that it would be something you could have a random computer "register" with. I'd imagine it'd be some sort of non-dynamic system, similar to creating a domain server authoritative for your particular domain (most people don't have fancy systems to update dns entries dynamically; at least I never have).
So did you mean "all code" or "all code that is written in a proper and reasonable manner"? To put it another way, are you tryting to assert that it would be impossible for a team to just drop *everything* into one function?
I would argue that it would be impossible for a team to drop *everything* into one function today; In the past, it may have been possible to do so with raw access to hardware. However, today it is not. Make an OS call? You're calling a function. Call something in the std lib, you're calling a function.
However, I see the point you're trying to make.
Yes, it is possible to write disasterously large functions that do not represent small, specific tasks. And yes, I would tend to think that someone who did this wasn't writing very good code.
I'm also looking back at the post I originally replied to... and I think I must had read it wrong or something because I think that's exactly what he was trying to say... oh well. Happens.:)
Instead of spending loads of $$ to project an image, why not spend it towards FIXING THE BUGS and SECURITY HOLES in their stuff?...because with 50 BILLION dollars and over 50,000 employees, they don't have enough money available or people working to fixing bugs and security holes, let alone spend a few million dollars on product placement...
You're assuming of course that the xbox is capable of reading burned disks... Dunno how it is for dvds, but there are a lot of dvd players that won't read burned cds...
In particular, they say that Palladium (of which this BIOS is a crucial part) will prevent hardware keystroke sniffers, by encrypting everything between the keyboard and the PC. The problem with this argument is that the encryption keys are held by Microsoft, not the computer owner....because the user HAS to have the encryption keys in order to verify that the key you typed on your keyboard is the same as the letter that pops up on screen...
As a perfect example of software not being perfect, slashdot decided to munch part of my last post... resubmitting...
So you think buffer overflows, for example, can never be 100% avoided?
Do you think all buffer overflows are as simple as the following code?
// data = char * passed into function char * foo = new char[255]; while (*data != '\0') *foo++ = *data++;
They're not. The scarry thing is that the above code could very well be guaranteed to never overflow if the data * passed in is guaranteed to be be less than 255 chars. Someone later on 20 steps removed from this function may change that, suddenly causing a buffer overflow. But this type of overflow is very easy to detect and fix. It gets harder when you have different modules interacting with the same piece of data from multiple threads. There are also buffer overflows caused by integer overflows. And so on, and so on, and so on. There are hundreds of books written on the topic describing how to prevent, detect, and fix buffer overflows. And none of them are the size of a pamphlet. They're usually textbook sized. If it was an easy problem, the books would not be long, and there wouldn't be many of them written.
You're also crazy if you don't think that a company like Microsoft doesn't take measures to fix and correct problems similar to the reported problem. The number of potential exploits fixed during the development of Win2k3 was well in excess of 10k if I remember correctly. When a flaw is discovered, all you can do is learn from it, fix it, and try to make sure it doesn't happen again. The latter involves writing tests to verify that a regression doesn't occur in the future and writing tools to scan for similar problems. Code reviews can be employed, though it's of dubious value after about 4 people who know the code look at it (code reviews are all but useless if they're being performed by someone unfamiliar with the code in question, and studies show that the number of defects found after 4 people look at it fall off sharply -- the studies also correspond with my personal experience in the matter, for what it's worth).
I don't see a level of diligence any where near approaching that
And what level of diligence can you see? All you see are the patches. You don't have any insight about what goes on inside the company, or what they do to catch or prevent these sort of problems.
But I don't think it's acceptable for a manufacturer to simply wash their hands of any responsibility
A manufacturer washing their hands of responsibility wouldn't bother to fix their product at all. There is a difference between responsibility and liability.
we don't accept that in other walks of life and I still don't see a good reason that the same principle shouldn't apply to software
Sure we do. When you buy a new car you have a warantee for x miles or years against defects (analogous to how long a particular piece of software is supported). After that warranty expires, if a part fails due to a problem on the manufacturers side (ie: not normal wear 'n tear) you still have to pay to get it replaced. Even if the part does fail under waranty, you will have to make arrangements to get your car back to the dealership (usually at your own cost; higher end cars/dealerships will tow your car for you and give you a loaner though). When you buy a cheap radio and one of the knobs fall off, most people don't do anything about it. When you buy a shirt and a button comes off after the 2nd time you wash it, can you take it back to the store and get a replacement? Sure people bitch about it, but they don't DO anything about it. And if they tried they'd get nowhere anyway.
I'll also retract what I said in my first post - your reasoning is lucid, it just isn't convincing (to me, at least;)
So you think buffer overflows, for example, can never be 100% avoided?
Do you think all buffer overflows are as simple as the following code?// data = char * passed into function char * foo = new char[255]; while (*data != '\0') *foo++ = *data++;
They're not. The scarry thing is that the above code could very well be guaranteed to never overflow if the data * passed in is guaranteed to be I don't see a level of diligence any where near approaching that
And what level of diligence can you see? All you see are the patches. You don't have any insight about what goes on inside the company, or what they do to catch or prevent these sort of problems.
But I don't think it's acceptable for a manufacturer to simply wash their hands of any responsibility
A manufacturer washing their hands of responsibility wouldn't bother to fix their product at all. There is a difference between responsibility and liability.
we don't accept that in other walks of life and I still don't see a good reason that the same principle shouldn't apply to software
Sure we do. When you buy a new car you have a warantee for x miles or years against defects (analogous to how long a particular piece of software is supposed). After that warranty expires, if a part fails due to a problem on the manufacturers side (ie: not normal wear 'n tear) you still have to pay to get it replaced. Even if the part does fail under waranty, you will have to make arrangements to get your car back to the dealership (usually at your own cost; higher end cars/dealerships will tow your car for you and give you a loaner though). When you buy a cheap radio and one of the knobs fall off, most people don't do anything about it. When you buy a shirt and a button comes off after the 2nd time you wash it, can you take it back to the store and get a replacement? Sure people bitch about it, but they don't DO anything about it. And if they tried they'd get nowhere anyway.
I'll also retract what I said in my first post - your reasoning is lucid, it just isn't convincing (to me, at least;):) I personally think that it is possible to produce higher quality products. However, I don't think it is possible to do so at a cost people are willing to pay. Look at the cost for producing software where people's lives are affected as opposed to a PC app -- it's an insane difference.
I also don't think it is an "easy" problem (if it were, it'd be done already). I think that most of the people who claim that it is haven't worked on a software project of any significant size.
So long as each is properly written (verify all input, verify that the state remains sane, and such), why does it matter how many you put together?
Complexity grows exponentially with the number of components. At some point the computing time required to validate every interaction is greater than the effort required to crack RC5 encryption keys.
Interactions are predictable no matter how complex a piece of software is. Your failure to track them is not the fault of the software.
Correct. However, programmers are human, and there isn't an automated way to verify all interactions are 100% correct for complex systems. However, people like you assume that programmers either a) aren't human or b) there is a way to verify all interactions are 100% correct. This is the misconception behind all of the assumptions that programming is "easy" or it should be possible to guarantee 100% correct operation of a piece of software.
And I would think a prudent person would not then make exactly the same mistakes again in newly developed software (though this may not be exactly what this particular lawsuit is about.
The fact that it is a "mistake" precludes it from being 100% preventable. You take actions to catch the error in the future (ex: write code scanning tools) but nothing is 100%.
Incidentally, I also think there's a huge difference between binaries and source, primarily that the user is unable to rectify a problem binary and is utterly dependent on the manufacturer. It's that dependence that ought to create some liability on the part of the manufacturer.
Both approaches have flaws. My mother wouldn't understand source code if she looked through it. She'd have to pay someone to "fix" her problem for her. Additionally, such schemes could easily be worked around -- Microsoft could provide the source for windows (and only the source) -- but I guarantee you that you or I wouldn't be able to build it. So they could provide the source, which you give to an authorized 3rd party that Microsoft has trained in how to build windows, to "build" your copy for you (for a fee of course). At which point that company hands you the binary. And you're no better off. In fact, because you propose reduced liability for companies which provide the source, "maintenance" schemes could be concocted which would require the vast majority of people to "hire" someone to build fixes for them.
We seem to have got into a circular argument - I say use of small separate modules is fundamental to design. I still maintain that there is a big difference between "functions" within a monolithic program, and completely separate modules.
Breaking stuff into separate modules (where module=collection of functions or a set of functionality) does not guarantee you that the code won't be a mess of interdependencies. Just as writing OO code doesn't guarantee you that your "dog" class doesn't have information that should belong in the "animal" class.
Challenge declined:) Note also that there has been considerably more than 2 seconds thought put into the development of sendmail, and there have even been re-writes. Yet it's still crappy
I said that putting lots of thought into a design MIGHT get you a good design. It isn't a given. There is no single magic process that guarantees you stable, secure, error free code. If there were, everyone would use it. There are techniques you can use to help you get there that work better than average, but they don't always work and can always be defeated by poor programming or design.
How bad does it have to be before it's negligence?
Webster defines negligence as the "failure to exercise the care that a prudent person usually exercises." The lawsuit at hand is blaming Microsoft for the problems people are occuring because they have been releasing fixes for the flaws that they find. I don't think that qualifies as negligence, as I would think that a prudent person would fix their software instead of leaving it vulnerable.
The advantage isn't acheived through the use of small modules (as I said, every program is made up of them). The difference is the design of the software itself.
Crappy software is software someone spent 2 seconds thinking about before they wrote a single line of code (poor design). Good software is software someone spent months designing and planning out before writing a single line of code (potentially good design).
Sendmail is an example of crappy design. I challenge you to look through the code and tell me it isn't. Qmail is an example of a good design.
Incidentally, my experience shows that former approach generally takes longer than the latter to end up with a finished product.
A do-it-all program isn't inheriantly flawed. There are two things that make software error prone: Design flaws, and programmer errors. These flaws can happen in any piece of software.
The real question is, what can be done to prevent, catch, and fix those errors?
Sorry, that's all hardware. Programmer would try to restart the car, then suggest that the driver hit the gas instead of the brake and would tell the driver to 'keep on driving and let me know if it happens again'.
A good program DOES check hardware. The person you "describe" should be fired for gross incompetance.
If your code isn't properly split into many small, specific tasks, then you're doing something wrong.
If you make statements like this, you obviously don't have a clue about programming anything more than little helper utilities.
All code is split into small, specific tasks. They're call functions.
The interation between the small specific tasks is where you have problems. You get even more problems when parts of the system have to maintain some sort of "state" about what's going on.
Mix 1000 of these things together, and it's hard to keep working right. Now mix 10,000 of them. Now deal with 100,000 of them.
Next, throw a few extra simple things like threads into the mix and tell me that you will know the implication of the interaction of all of those pieces at any given moment in time.
Doesn't M$ have a history of penalizing people that report bugs, including pursuing them with legal action ?
No. If they did, the people that find the exploits wouldn't bother reporting them. You'll notice that in a lot of the knowledgebase articles they give credit to the people who discovered the problem and thank them for their help.
It goes; A Mechanical Engineer, Marketer and Programmer were driving in the mountains, when the car's brakes failed and they crashed into one of the breakdown barriers (big mounds of gravel to stop trucks).
*truncated*
A good programmer would check under the car (look through the logs) and find no damage. He would also check the check fluid levels (system configuration) and see that the fluid levels were ok. He would also check to make sure that the make sure the brakes were on the car (check to see if the brake feature was installed) to make sure the user didn't remove them. The programmer would also take apart the brakes (step through the code) to make sure that when the user hit the brake pedal that the brakes were applied. He would also investigate the throttle, to make sure it didn't get stuck. If no problems were found, he would drive down the hill in his own car in and attempt to reproduce the conditions of the failure.
After all of the above steps have been taken, no clues as to why the car didn't stop have been found. The programmer secretly believes that the user didn't hit the brakes, but instead hit the gas pedal (the user clicked quit instead of cancel). This theory is reinfoced by the skidmarks left on the road at approximately the point the user claimed to have hit the brake pedal, in addition to the manner in which the gravel was scattered onto the road, and evidence indicating that the car was traveling at a speed much higher than the user claimed at the point of impact.
The programmer would then suggest pushing the car back to the top of the hill to see if the problem happens again. At which point it doesn't.
There are two distinct types of bugs with software: * bugs exposed through normal use of the program (you perform actions with the components designed for use by the enduser and something bad happens) * bugs exposed through by non-normal use of the program (you perform actions using components external to the system and something bad happens).
The first one is analogous to a car manufacturing defect (sunroof doesn't open, tire blows up, vehicle rolls over), advertised security features on the car don't work, etc. The second is analogous to the user putting the wrong kind of oil on the car, a thief bypassing the security features of the vehicle, breaking a window, etc.
People expect the first kind of problem to be fixed; the second kind of problem people live with.
Today it's a fairly straightforward process to handle the first type of error -- you know how the software is EXPECTED to work, and the various ways to manipulate it. It isn't an easy problem and nothing will ever be 100% right, but it isn't unreasonable to expect software to ship without these kinds of bugs. Most security flaws do NOT exploit this type of problem.
It isn't a straightforward process to anticipate every possible way someone might try to "use" your software from an external source. THAT is the problem with software security, and that is why these sorts of bugs are hard to find -- it's because they are UNEXPECTED. If it was an expected condition, the flaw wouldn't be there in the first place. And to make matters worse, the amount of unexpected input/manipulation a piece of software could receive is *infinite*.
DirectX allows application to intercept any key combination, including the three-finger salute.
Please show me how you can intercept ctrl-alt-del using DirectX. All of the documentation I've seen indicates that it can't be done. The lack of login-screen spoofing apps would tend to back the documented side of things.
It is possible to capture ctrl-alt-del on Win9x, however I haven't seen a way to do it using DirectX on Win9x.
I can find no way to intercept ctl-alt-del, and I have never seen an NT application which was able to do so. I believe it is possible to do so on Win9x however.
It is possible to intercept any other key combination on NT (DirectX basically treats the keyboard as a joystick device), however the three finger salute is treated as a special case that the OS always handles.
The LCD remote is a pretty standard feature in iRiver products (from what I can tell anyway), and is VERY handy. Allows you to keep the bulky part of the player packed away in your backpack (or luggage, or carryone) while being able to actually use the unit. Also keeps the main part of the unit smaller for when portability is more important than having an lcd screen.
As for the navigation system, if it works anything like the cd-based iRiver mp350 (an EXCELLENT cd based mp3 player; I *love* mine), the stucture is based on how you place files & folders on the unit. "Root" is the name of the folder without a directory, with everything else inheriting the folder names you give them. The navigation of the directories is very intuitive, especially considering the lack of buttons available.
On my particular player, there are 3 fwd/back/in buttons. One of those buttons is used to move forward/backward through tracks. Press it in for a few seconds. You get a file list of the current directory. Use the fwd/back buttons to move through the list (hold fwd/back to move quickly instead of one song at a time). To select a song, or look at another directory, press in again. To back out a directory level, hold that button in for a few seconds.
This sounds complicated, but it is actually quite simple in practice.
(what do the other two do? One controls fast forward/reverse/tuner vs cd, the other controls volume/settings; there are also two "normal" buttons for play/pause + stop).
Slashdot Mirror
Here's one to get you started: "I'm working from home today about I don't want replies to my business email sent to my home account."
Three solutions:
1) Use your work's SMTP server
2) Change your reply-to address
3) Add your ISP's SMTP server to the "allowed to send email for this domain" list at work
This would also cause serious problems for mobile users -- if I'm on the road, who knows what ISP I'll be connecting to. However, I probably want my From: address to stay the same no matter where I'm connected.
It doesn't matter what ISP you're connecting to on the road -- you should still be able to use your home ISP's SMTP server.
Traveling mailman problem:
In this situation, wouldn't you just connect to the ISP's SMTP server and send the email? This system is designed to authenticate SMTP servers, not people connecting to them.
Any mailserver internal to a network
If your internal server tries to send email from reported to be from cox.net (or whatever their domain is) then yes, you'll have a problem. Don't do that.
However, if you own mydomain.com, and have your SPF server report it's ip as an authoritative SMTP server for sending mail from mydomain.com, you don't have any problems.
It makes filtering spam a lot easier. For one thing, you no longer have spoofed email addresses to deal with. Now, email that claims to come from "aol.com" will really come from aol.com, instead of some spam server.
Secondly, in order to register a domain you need to provide some sort of cc information which would imply that there would be a way to track down spammers (assuming they didn't use stolen cc's, and I wouldn't put that past 'em -- but then they're commiting an actual crime and this kind of thing is much easier to put people in jail for than the current crimes they commit).
Thirdly, it adds costs to the spammer's bottomline. Reducing "profitablity" from spamming == good way to reduce spamming; if it cost them a new domain for every 10000 spams they send out, it'd cost them $800 to send one million spam emails. Not to mention the time it takes for domain info to propigate after registering it, etc (spams will fail to get through until the dns info exists).
As far as registering the victim hostname with the SFP server, that would imply that you would have access to the SFP server. I doubt that it would be something you could have a random computer "register" with. I'd imagine it'd be some sort of non-dynamic system, similar to creating a domain server authoritative for your particular domain (most people don't have fancy systems to update dns entries dynamically; at least I never have).
So did you mean "all code" or "all code that is written in a proper and reasonable manner"? To put it another way, are you tryting to assert that it would be impossible for a team to just drop *everything* into one function?
... and I think I must had read it wrong or something because I think that's exactly what he was trying to say ... oh well. Happens. :)
I would argue that it would be impossible for a team to drop *everything* into one function today; In the past, it may have been possible to do so with raw access to hardware. However, today it is not. Make an OS call? You're calling a function. Call something in the std lib, you're calling a function.
However, I see the point you're trying to make.
Yes, it is possible to write disasterously large functions that do not represent small, specific tasks. And yes, I would tend to think that someone who did this wasn't writing very good code.
I'm also looking back at the post I originally replied to
Instead of spending loads of $$ to project an image, why not spend it towards FIXING THE BUGS and SECURITY HOLES in their stuff? ...because with 50 BILLION dollars and over 50,000 employees, they don't have enough money available or people working to fixing bugs and security holes, let alone spend a few million dollars on product placement...
You're assuming of course that the xbox is capable of reading burned disks... Dunno how it is for dvds, but there are a lot of dvd players that won't read burned cds...
In particular, they say that Palladium (of which this BIOS is a crucial part) will prevent hardware keystroke sniffers, by encrypting everything between the keyboard and the PC. The problem with this argument is that the encryption keys are held by Microsoft, not the computer owner. ...because the user HAS to have the encryption keys in order to verify that the key you typed on your keyboard is the same as the letter that pops up on screen...
As a perfect example of software not being perfect, slashdot decided to munch part of my last post ... resubmitting ...
// data = char * passed into function
;)
:) I personally think that it is poss
So you think buffer overflows, for example, can never be 100% avoided?
Do you think all buffer overflows are as simple as the following code?
char * foo = new char[255];
while (*data != '\0') *foo++ = *data++;
They're not. The scarry thing is that the above code could very well be guaranteed to never overflow if the data * passed in is guaranteed to be be less than 255 chars. Someone later on 20 steps removed from this function may change that, suddenly causing a buffer overflow. But this type of overflow is very easy to detect and fix. It gets harder when you have different modules interacting with the same piece of data from multiple threads. There are also buffer overflows caused by integer overflows. And so on, and so on, and so on. There are hundreds of books written on the topic describing how to prevent, detect, and fix buffer overflows. And none of them are the size of a pamphlet. They're usually textbook sized. If it was an easy problem, the books would not be long, and there wouldn't be many of them written.
You're also crazy if you don't think that a company like Microsoft doesn't take measures to fix and correct problems similar to the reported problem. The number of potential exploits fixed during the development of Win2k3 was well in excess of 10k if I remember correctly. When a flaw is discovered, all you can do is learn from it, fix it, and try to make sure it doesn't happen again. The latter involves writing tests to verify that a regression doesn't occur in the future and writing tools to scan for similar problems. Code reviews can be employed, though it's of dubious value after about 4 people who know the code look at it (code reviews are all but useless if they're being performed by someone unfamiliar with the code in question, and studies show that the number of defects found after 4 people look at it fall off sharply -- the studies also correspond with my personal experience in the matter, for what it's worth).
I don't see a level of diligence any where near approaching that
And what level of diligence can you see? All you see are the patches. You don't have any insight about what goes on inside the company, or what they do to catch or prevent these sort of problems.
But I don't think it's acceptable for a manufacturer to simply wash their hands of any responsibility
A manufacturer washing their hands of responsibility wouldn't bother to fix their product at all. There is a difference between responsibility and liability.
we don't accept that in other walks of life and I still don't see a good reason that the same principle shouldn't apply to software
Sure we do. When you buy a new car you have a warantee for x miles or years against defects (analogous to how long a particular piece of software is supported). After that warranty expires, if a part fails due to a problem on the manufacturers side (ie: not normal wear 'n tear) you still have to pay to get it replaced. Even if the part does fail under waranty, you will have to make arrangements to get your car back to the dealership (usually at your own cost; higher end cars/dealerships will tow your car for you and give you a loaner though). When you buy a cheap radio and one of the knobs fall off, most people don't do anything about it. When you buy a shirt and a button comes off after the 2nd time you wash it, can you take it back to the store and get a replacement? Sure people bitch about it, but they don't DO anything about it. And if they tried they'd get nowhere anyway.
I'll also retract what I said in my first post - your reasoning is lucid, it just isn't convincing (to me, at least
So you think buffer overflows, for example, can never be 100% avoided?
// data = char * passed into function
;) :) I personally think that it is possible to produce higher quality products. However, I don't think it is possible to do so at a cost people are willing to pay. Look at the cost for producing software where people's lives are affected as opposed to a PC app -- it's an insane difference.
Do you think all buffer overflows are as simple as the following code?
char * foo = new char[255];
while (*data != '\0') *foo++ = *data++;
They're not. The scarry thing is that the above code could very well be guaranteed to never overflow if the data * passed in is guaranteed to be I don't see a level of diligence any where near approaching that
And what level of diligence can you see? All you see are the patches. You don't have any insight about what goes on inside the company, or what they do to catch or prevent these sort of problems.
But I don't think it's acceptable for a manufacturer to simply wash their hands of any responsibility
A manufacturer washing their hands of responsibility wouldn't bother to fix their product at all. There is a difference between responsibility and liability.
we don't accept that in other walks of life and I still don't see a good reason that the same principle shouldn't apply to software
Sure we do. When you buy a new car you have a warantee for x miles or years against defects (analogous to how long a particular piece of software is supposed). After that warranty expires, if a part fails due to a problem on the manufacturers side (ie: not normal wear 'n tear) you still have to pay to get it replaced. Even if the part does fail under waranty, you will have to make arrangements to get your car back to the dealership (usually at your own cost; higher end cars/dealerships will tow your car for you and give you a loaner though). When you buy a cheap radio and one of the knobs fall off, most people don't do anything about it. When you buy a shirt and a button comes off after the 2nd time you wash it, can you take it back to the store and get a replacement? Sure people bitch about it, but they don't DO anything about it. And if they tried they'd get nowhere anyway.
I'll also retract what I said in my first post - your reasoning is lucid, it just isn't convincing (to me, at least
I also don't think it is an "easy" problem (if it were, it'd be done already). I think that most of the people who claim that it is haven't worked on a software project of any significant size.
So long as each is properly written (verify all input, verify that the state remains sane, and such), why does it matter how many you put together?
Complexity grows exponentially with the number of components. At some point the computing time required to validate every interaction is greater than the effort required to crack RC5 encryption keys.
Interactions are predictable no matter how complex a piece of software is. Your failure to track them is not the fault of the software.
Correct. However, programmers are human, and there isn't an automated way to verify all interactions are 100% correct for complex systems. However, people like you assume that programmers either a) aren't human or b) there is a way to verify all interactions are 100% correct. This is the misconception behind all of the assumptions that programming is "easy" or it should be possible to guarantee 100% correct operation of a piece of software.
And I would think a prudent person would not then make exactly the same mistakes again in newly developed software (though this may not be exactly what this particular lawsuit is about.
The fact that it is a "mistake" precludes it from being 100% preventable. You take actions to catch the error in the future (ex: write code scanning tools) but nothing is 100%.
Incidentally, I also think there's a huge difference between binaries and source, primarily that the user is unable to rectify a problem binary and is utterly dependent on the manufacturer. It's that dependence that ought to create some liability on the part of the manufacturer.
Both approaches have flaws. My mother wouldn't understand source code if she looked through it. She'd have to pay someone to "fix" her problem for her. Additionally, such schemes could easily be worked around -- Microsoft could provide the source for windows (and only the source) -- but I guarantee you that you or I wouldn't be able to build it. So they could provide the source, which you give to an authorized 3rd party that Microsoft has trained in how to build windows, to "build" your copy for you (for a fee of course). At which point that company hands you the binary. And you're no better off. In fact, because you propose reduced liability for companies which provide the source, "maintenance" schemes could be concocted which would require the vast majority of people to "hire" someone to build fixes for them.
We seem to have got into a circular argument - I say use of small separate modules is fundamental to design. I still maintain that there is a big difference between "functions" within a monolithic program, and completely separate modules.
:) Note also that there has been considerably more than 2 seconds thought put into the development of sendmail, and there have even been re-writes. Yet it's still crappy
Breaking stuff into separate modules (where module=collection of functions or a set of functionality) does not guarantee you that the code won't be a mess of interdependencies. Just as writing OO code doesn't guarantee you that your "dog" class doesn't have information that should belong in the "animal" class.
Challenge declined
I said that putting lots of thought into a design MIGHT get you a good design. It isn't a given. There is no single magic process that guarantees you stable, secure, error free code. If there were, everyone would use it. There are techniques you can use to help you get there that work better than average, but they don't always work and can always be defeated by poor programming or design.
How bad does it have to be before it's negligence?
Webster defines negligence as the "failure to exercise the care that a prudent person usually exercises." The lawsuit at hand is blaming Microsoft for the problems people are occuring because they have been releasing fixes for the flaws that they find. I don't think that qualifies as negligence, as I would think that a prudent person would fix their software instead of leaving it vulnerable.
The advantage isn't acheived through the use of small modules (as I said, every program is made up of them). The difference is the design of the software itself.
Crappy software is software someone spent 2 seconds thinking about before they wrote a single line of code (poor design). Good software is software someone spent months designing and planning out before writing a single line of code (potentially good design).
Sendmail is an example of crappy design. I challenge you to look through the code and tell me it isn't. Qmail is an example of a good design.
Incidentally, my experience shows that former approach generally takes longer than the latter to end up with a finished product.
A do-it-all program isn't inheriantly flawed. There are two things that make software error prone: Design flaws, and programmer errors. These flaws can happen in any piece of software.
The real question is, what can be done to prevent, catch, and fix those errors?
Sorry, that's all hardware. Programmer would try to restart the car, then suggest that the driver hit the gas instead of the brake and would tell the driver to 'keep on driving and let me know if it happens again'.
A good program DOES check hardware. The person you "describe" should be fired for gross incompetance.
...because we all know that that BMW has an undocumented 802.11b device in there somewhere that polls the internet periodically for virii...
If your code isn't properly split into many small, specific tasks, then you're doing something wrong.
If you make statements like this, you obviously don't have a clue about programming anything more than little helper utilities.
All code is split into small, specific tasks. They're call functions.
The interation between the small specific tasks is where you have problems. You get even more problems when parts of the system have to maintain some sort of "state" about what's going on.
Mix 1000 of these things together, and it's hard to keep working right. Now mix 10,000 of them. Now deal with 100,000 of them.
Next, throw a few extra simple things like threads into the mix and tell me that you will know the implication of the interaction of all of those pieces at any given moment in time.
Doesn't M$ have a history of penalizing people that report bugs, including pursuing them with legal action ?
No. If they did, the people that find the exploits wouldn't bother reporting them. You'll notice that in a lot of the knowledgebase articles they give credit to the people who discovered the problem and thank them for their help.
It goes;
A Mechanical Engineer, Marketer and Programmer were driving in the mountains, when the car's brakes failed and they crashed into one of the breakdown barriers (big mounds of gravel to stop trucks).
*truncated*
A good programmer would check under the car (look through the logs) and find no damage. He would also check the check fluid levels (system configuration) and see that the fluid levels were ok. He would also check to make sure that the make sure the brakes were on the car (check to see if the brake feature was installed) to make sure the user didn't remove them. The programmer would also take apart the brakes (step through the code) to make sure that when the user hit the brake pedal that the brakes were applied. He would also investigate the throttle, to make sure it didn't get stuck. If no problems were found, he would drive down the hill in his own car in and attempt to reproduce the conditions of the failure.
After all of the above steps have been taken, no clues as to why the car didn't stop have been found. The programmer secretly believes that the user didn't hit the brakes, but instead hit the gas pedal (the user clicked quit instead of cancel). This theory is reinfoced by the skidmarks left on the road at approximately the point the user claimed to have hit the brake pedal, in addition to the manner in which the gravel was scattered onto the road, and evidence indicating that the car was traveling at a speed much higher than the user claimed at the point of impact.
The programmer would then suggest pushing the car back to the top of the hill to see if the problem happens again. At which point it doesn't.
There are two distinct types of bugs with software:
* bugs exposed through normal use of the program (you perform actions with the components designed for use by the enduser and something bad happens)
* bugs exposed through by non-normal use of the program (you perform actions using components external to the system and something bad happens).
The first one is analogous to a car manufacturing defect (sunroof doesn't open, tire blows up, vehicle rolls over), advertised security features on the car don't work, etc. The second is analogous to the user putting the wrong kind of oil on the car, a thief bypassing the security features of the vehicle, breaking a window, etc.
People expect the first kind of problem to be fixed; the second kind of problem people live with.
Today it's a fairly straightforward process to handle the first type of error -- you know how the software is EXPECTED to work, and the various ways to manipulate it. It isn't an easy problem and nothing will ever be 100% right, but it isn't unreasonable to expect software to ship without these kinds of bugs. Most security flaws do NOT exploit this type of problem.
It isn't a straightforward process to anticipate every possible way someone might try to "use" your software from an external source. THAT is the problem with software security, and that is why these sorts of bugs are hard to find -- it's because they are UNEXPECTED. If it was an expected condition, the flaw wouldn't be there in the first place. And to make matters worse, the amount of unexpected input/manipulation a piece of software could receive is *infinite*.
They're claiming that releasing a security fix is "unfair competition." The people sueing don't want Microsoft to release security fixes at all...
What kind of crap is that?
DirectX allows application to intercept any key combination, including the three-finger salute.
Please show me how you can intercept ctrl-alt-del using DirectX. All of the documentation I've seen indicates that it can't be done. The lack of login-screen spoofing apps would tend to back the documented side of things.
It is possible to capture ctrl-alt-del on Win9x, however I haven't seen a way to do it using DirectX on Win9x.
I can find no way to intercept ctl-alt-del, and I have never seen an NT application which was able to do so. I believe it is possible to do so on Win9x however.
It is possible to intercept any other key combination on NT (DirectX basically treats the keyboard as a joystick device), however the three finger salute is treated as a special case that the OS always handles.
The OS deals just fine with the shitty app (ie: it stays running without effecting system stability).
The LCD remote is a pretty standard feature in iRiver products (from what I can tell anyway), and is VERY handy. Allows you to keep the bulky part of the player packed away in your backpack (or luggage, or carryone) while being able to actually use the unit. Also keeps the main part of the unit smaller for when portability is more important than having an lcd screen.
As for the navigation system, if it works anything like the cd-based iRiver mp350 (an EXCELLENT cd based mp3 player; I *love* mine), the stucture is based on how you place files & folders on the unit. "Root" is the name of the folder without a directory, with everything else inheriting the folder names you give them. The navigation of the directories is very intuitive, especially considering the lack of buttons available.
On my particular player, there are 3 fwd/back/in buttons. One of those buttons is used to move forward/backward through tracks. Press it in for a few seconds. You get a file list of the current directory. Use the fwd/back buttons to move through the list (hold fwd/back to move quickly instead of one song at a time). To select a song, or look at another directory, press in again. To back out a directory level, hold that button in for a few seconds.
This sounds complicated, but it is actually quite simple in practice.
(what do the other two do? One controls fast forward/reverse/tuner vs cd, the other controls volume/settings; there are also two "normal" buttons for play/pause + stop).