JACK: I'm a recall coordinator. My job is to apply the formula.
Take the number of vehicles in the field, (A), and multiply it by the probable rate of failure, (B), then multiply the result by the average out-of-court settlement, (C). A times B times C equals X...
If X is less than the cost of a recall, we don't do one.
BUSINESS WOMAN: Are there a lot of these kinds of accidents?
JACK: Oh, you wouldn't believe.
BUSINESS WOMAN:... Which... car company do you work for?
I don't know why people keep on going about advancements in decaffinated coffee. Everybody in the scientific community knows that God intended for coffee to be caffinated!
It's so we start a discussion on the pro's and con's of the arguments, so that we all have a better understanding of the issues involved.
In my view, the online technical community (eg: slashdotters) is becoming increasingly aware of such issues (copyright, freedom, general rights, etc), and appear to be more actively dicusssing and doing anything about them than any other group. I think one of the reasons for this is that these issues are becoming more and more important in the IT field.
It's important to discuss these issues when they come up in a popular column/forum/wherever because we're not the only ones who read them: other people less aware of the reality of the situation also read them. If we know what the issues are, then hopefully the FUD won't propogate from us, or through us. I think a lot of people who aren't very "IT Aware" generally look to the IT 'professionals' for any issues that may have an impact on IT, including the type of crap that Dvorak spews forth.
Dvoraks' comments on Creative Commons might not strictly speaking be "News for nerds", but I think it's definately "Stuff that matters", given the general sort of topics we do cover here.
(I realise that I perhaps paint a picture of a supposed "Utopia", but I'm just talking about "in general, wouldn't it be nice" terms:)
Wait, it gets better. The screenshots show that he downloaded an episode of The Family Guy and this install popped up with it. Anyone want to take any bets on whether or not they had permission to distribute The Family Guy? What do you think the MPAA's going to do to them when they find out they're "monetizing" illegal downloads of their member's products? Bet it makes the lawsuits we've seen against fileshares look tame, and bet the owners of Direct Revenue will be able to put up their own goats.cx photos once it's over with.
I think it gets even better. The **AA has two options: sue the pants off them, or set up a business model with them. If they do the former, fine. But if they do the later, doesn't that almost legitimise the download?
Either way we win: no more spyware (from this company, anyway); or legitimate media downloads (working out how to avoid the spyware should be trivial).
Office is a separate product. That is, it's not Windows. If the EU expects that Office should be able to play embedded media files (as the example states), then presumably it requires a media player to do so. Is it reasonable to expect that Office could use any available media player to do so, or just Windows Media Player?
If it's the former, then you'd need a standardised API (not a bad thing in itself) or something similar, to allow Office to find and use the available players. If it's the later, then why don't they bundle Windows media player with Office?
In principle I like the first option better, but it raises a question: what are the obligations for other software packages? Disregarding who makes what for a while, say you've released a software package that utilises the functionality of another (separate) software package. Say that separate package has other equivalents out there. Applying a fair and even hand the the idea, then is your software obliged to be able to use the equivalents, or can it just use it's preferred package?
What are the possible rammifications if MD5 is confirmed to have a collision? What other hashing algo's are there that may take its place? And even if it does have collisions, is that serious enough to break many security systems already in place?
It depends on how the collision is discoverred. If the collision is derived using brute force methods ('hard'), then there's probably not much to worry about. If the collision is discoverred using the result hash and working back from there ('easy'), then that's another story. The security implications depend on the application of the hashing algorithm.
For example: lets suppose we use MD5 hash of user passwords, and we check the MD5 hash of the password that the user supplied when attempting to authenticate against the one that we have. If the hash's match, then we assume that the user enterred in the correct password, and we validate them.
Why do we store the MD5 hash as opposed to the original password itself? Because the MD5 hash is (was) supposedly 'secure', meaning that we can't derive the original password from it (except via brute force or other password guessing techniques), in the event that the MD5 hash is compromised. So, even if the 1337 h4x0r managed to get the hash, it doesn't do him any good.
Now suppose that if there was suddenly a method of easilly deriving data that will generate a matching MD5 hash. If the 1337 h4x0r is able to get the MD5 hash, then he can generate a password that he can authenticate with. If that's the case, then storing the MD5 hash is no better than storing the plain text password.
This (as far as I understand it) is pretty much what happenned with the old DES style password hashes that we used to use in unix.
This is a problem with hash' in general. Because the algorithm will accept any input to generate a hash, theoretically the set inputs is infinite, and every input will generate a hash value from a finite set of hashes.
The approach to reducing the problem is to 'reduce' the infinite input set to a 'smaller' infinite set, or a finite set (f you could define a reasonably large finite set with no (or very few collisions) then it's not a problem). That way you not only have to find a string that generates the same hash, but is also within the input set, therfore satisfying two conditions.
In terms of using MD5 hashes for passwords, this should actually be fairly trivial (if required at all). The input set is already fairly limited to certain characters (a-zA-Z0-9...). It can be restricted further by placing limits on the size of the string. Then you can also implement a good password policy. These all limit the size of the input set. The goal is to limit the input set such that even if another string was generated with the same hash, the chances of it being within the input set are very minimal. Then, the trick is that when you verify the MD5 hash, you also check to see if the input string was in the input set.
Another method would be to include some statistical information about the input string (a 'signature') in your hash. For example: lets suppose that 'm' is your input data, H() is your hashing function (say, MD5), and Sig() is a statistical function (it can really be just another hashing algorithm).
This is what's currently recorded:
passwdhash = H(m)
You can also record the statistical information:
passwdhash = H(m) || Sig(m)
(where '||' means you just concatenate the strings). This means that what the user supplies has to match two different criteria, therefore the input set is much smaller.
That should be good enough, but you can get as fancy as you need to by adding more criteria. Eg:
passwdhash = H(m) || Sig (m) || Sig( H(m) || Sig (m) )
The good thing about this is that on modern unix systems it's not too hard to implement something that will do this.
I used to run my X session in a vnc server. Then, my 'real' X session would just run a vnc client in full screen mode, which connected to the vnc server. At work (or wherever), I just create a tunnel to the home machine and run a vnc session over that. That was about 4 years or so ago, so I can't remember exactly how to set it up, but it worked reasonably well.
Then I discovered screen and that worked a lot much better for me - after all, I was mostly running console apps anyway (about the only graphical application I use regularly is a web browser).
If cars worked like exploits and patches, then every time a safer car came out, your car would suddenly become less safe than it had been yesterday- and it would become incumbent upon you to get it fixed. Cars, being physical objects, do not behave this way.
Ahh, but the in actuality the car was really unsafe the begin with, it's just that no one knew about it.
Your language is obscuring your logic. A car is "safe" or "unsafe". But a software vulnerability is unsafe when nobody knows about it and extremely unsafe when everyone does. Not like cars.Ahh, but the in actuality the car was really unsafe the begin with, it's just that no one knew about it.
If an exploit came out for your car, then your car isn't less safe, it's *perceived* to be less safe. The actual implicit 'safeness' of the car remains the same: the vulnerability existed before, and still exists exactly the same now. On the other hand: it *is* less safe because we know more information about it, such that those with ill intent can abuse the safety flaws, instead of not being able to because they don't know about them. I think that this line of thinking can be directly applied to software.
If you think about the second way of looking at it, then you might see what they're getting at: exposing problems provides a greater opportunity for the security flaws of the car/software to be exploited (at least until they're patched). I think that this completely ignores the fact that, as an above poster (c0dedude) said, if we criminalise the discovery of exploits, then only the criminals will know of the exploits (assertion: there will always be criminals). Sure, there *might* probably be *fewer* incidents of the exploit being abused because less people know about them, but sure as hell the software developer or the legitimate users of the software are going to know about it, at least until *after* it happens, and possibly not even then. The finding of faults in the software will be done during forensics - if they can find them at all.
However, when I made a conscious effort to start eating raw vegetables with *every* meal (and not just a carrot or so a day), I noticed that I started having fewer headaches, had more energy, and just generally felt all-around healthier. Now, if I don't eat my veggies, I find that those symptoms come right back. Carrots, celery, lettuce, and green peppers are almost always staples in my fridge.
Now see, what's going on here is that you've become addicted to these so-called "healthy" foods and have built up a dependency, as shown by your withdrawal symptoms. The effects of these food items are perceived increase in clarity and energy, and overall "health", exactly as you have described. But we all know the truth: you're addicted.
The government shut down several nominally free services provided by the government because private industry concerns complained that they were too successful and taking away business from the private sector.
The way you say make it sound as if the free government services were competing against the private sector. In that case I can see the argument from the private sector.
The way I see this case is that the government is choosing a product from the market that best suits them (ie: cheaper, whatever). That is, they're letting market forces dictate their product descisions. Isn't that capitalism at work - the very thing that SCO reckons linux prevents?
I'm still waiting for one country to trade in their Get a Free Clue card, and actually ask those of us involved in it for ideas on how to make it work - how to balance legal requirements for privacy and accountability with freedom to express.
why wait for them to ask? maybe we are just reactive? maybe we need to be proactive and go to them?
maybe we need to form a group, and go the the government and actually say something like "We are concerned with this, and we want to work with the govt to come up with some real solution that's not going to be a knee jerk reaction to anything..."?
I can't actually remember anywhere that we have done anything like that. maybe it's worth thinking about? maybe we could get some real response that way
there's an interesting novel dealing with such issues. It's called Metal Fatigue by Sean Williams.
the issues presented in the book raise the question of the impacts to society that such modification have.
for exaple, I can use this technology to repair damage to ones arm so that they can regain the use of that arm. on the other hand, I can use this technology to create your supersoldier.
what you then have to ask yourself is: what kind of impact is this going to have on the individual? For the arm dude, he regains agility. for the supersoldier, does he get a sense of superiority? of somehow being "Better" than everyone else?
what about his commanders? they have access to a better killing machine now. how are the general populacy going to react? how are the modified people going to react?
you haven't created a dude that's just stronger than everyone else, you have created a person that thinks he's stronger/better than everyone else. a deadly concoction if you ask me
Funny, but the Auditor General here in Perth has just completed a 5 year study that concludes that children playing "violent" computer games won't grow up to be any more violent or abusive than kids that don't...
Slashdot Mirror
Actually, yes.
JACK:
I'm a recall coordinator. My job is to apply the formula.
Take the number of vehicles in the field, (A), and multiply it by the probable rate of failure, (B), then multiply the result by the average out-of-court settlement, (C). A times B times C equals X...
If X is less than the cost of a recall, we don't do one.
BUSINESS WOMAN:
Are there a lot of these kinds of accidents?
JACK:
Oh, you wouldn't believe.
BUSINESS WOMAN: ... Which... car company do you work for?
JACK:
A major one.
This is rather troublesome. If these situations continue our representatives may be forced to actually read the legislation they're passing.
If I can't be bothered to rtfa, how can I expect the representatives to rtfl?
Aww man, the one time I choose to RTFA...
I don't know why people keep on going about advancements in decaffinated coffee. Everybody in the scientific community knows that God intended for coffee to be caffinated!
It's so we start a discussion on the pro's and con's of the arguments, so that we all have a better understanding of the issues involved.
In my view, the online technical community (eg: slashdotters) is becoming increasingly aware of such issues (copyright, freedom, general rights, etc), and appear to be more actively dicusssing and doing anything about them than any other group. I think one of the reasons for this is that these issues are becoming more and more important in the IT field.
It's important to discuss these issues when they come up in a popular column/forum/wherever because we're not the only ones who read them: other people less aware of the reality of the situation also read them. If we know what the issues are, then hopefully the FUD won't propogate from us, or through us. I think a lot of people who aren't very "IT Aware" generally look to the IT 'professionals' for any issues that may have an impact on IT, including the type of crap that Dvorak spews forth.
Dvoraks' comments on Creative Commons might not strictly speaking be "News for nerds", but I think it's definately "Stuff that matters", given the general sort of topics we do cover here.
(I realise that I perhaps paint a picture of a supposed "Utopia", but I'm just talking about "in general, wouldn't it be nice" terms :)
Wait, it gets better. The screenshots show that he downloaded an episode of The Family Guy and this install popped up with it. Anyone want to take any bets on whether or not they had permission to distribute The Family Guy? What do you think the MPAA's going to do to them when they find out they're "monetizing" illegal downloads of their member's products? Bet it makes the lawsuits we've seen against fileshares look tame, and bet the owners of Direct Revenue will be able to put up their own goats.cx photos once it's over with.
I think it gets even better. The **AA has two options: sue the pants off them, or set up a business model with them. If they do the former, fine. But if they do the later, doesn't that almost legitimise the download?
Either way we win: no more spyware (from this company, anyway); or legitimate media downloads (working out how to avoid the spyware should be trivial).
You can get around it this way:
Seems to work fine, but I'd much rather a nicer handler.
Office is a separate product. That is, it's not Windows. If the EU expects that Office should be able to play embedded media files (as the example states), then presumably it requires a media player to do so. Is it reasonable to expect that Office could use any available media player to do so, or just Windows Media Player?
If it's the former, then you'd need a standardised API (not a bad thing in itself) or something similar, to allow Office to find and use the available players. If it's the later, then why don't they bundle Windows media player with Office?
In principle I like the first option better, but it raises a question: what are the obligations for other software packages? Disregarding who makes what for a while, say you've released a software package that utilises the functionality of another (separate) software package. Say that separate package has other equivalents out there. Applying a fair and even hand the the idea, then is your software obliged to be able to use the equivalents, or can it just use it's preferred package?
"I got a network! Shit, out of range. I got a network! Shit, out of range. I got a network! Shit, out of range. Bugger."
It depends on how the collision is discoverred. If the collision is derived using brute force methods ('hard'), then there's probably not much to worry about. If the collision is discoverred using the result hash and working back from there ('easy'), then that's another story. The security implications depend on the application of the hashing algorithm.
For example: lets suppose we use MD5 hash of user passwords, and we check the MD5 hash of the password that the user supplied when attempting to authenticate against the one that we have. If the hash's match, then we assume that the user enterred in the correct password, and we validate them.
Why do we store the MD5 hash as opposed to the original password itself? Because the MD5 hash is (was) supposedly 'secure', meaning that we can't derive the original password from it (except via brute force or other password guessing techniques), in the event that the MD5 hash is compromised. So, even if the 1337 h4x0r managed to get the hash, it doesn't do him any good.
Now suppose that if there was suddenly a method of easilly deriving data that will generate a matching MD5 hash. If the 1337 h4x0r is able to get the MD5 hash, then he can generate a password that he can authenticate with. If that's the case, then storing the MD5 hash is no better than storing the plain text password.
This (as far as I understand it) is pretty much what happenned with the old DES style password hashes that we used to use in unix.
This is a problem with hash' in general. Because the algorithm will accept any input to generate a hash, theoretically the set inputs is infinite, and every input will generate a hash value from a finite set of hashes.
The approach to reducing the problem is to 'reduce' the infinite input set to a 'smaller' infinite set, or a finite set (f you could define a reasonably large finite set with no (or very few collisions) then it's not a problem). That way you not only have to find a string that generates the same hash, but is also within the input set, therfore satisfying two conditions.
In terms of using MD5 hashes for passwords, this should actually be fairly trivial (if required at all). The input set is already fairly limited to certain characters (a-zA-Z0-9...). It can be restricted further by placing limits on the size of the string. Then you can also implement a good password policy. These all limit the size of the input set. The goal is to limit the input set such that even if another string was generated with the same hash, the chances of it being within the input set are very minimal. Then, the trick is that when you verify the MD5 hash, you also check to see if the input string was in the input set.
Another method would be to include some statistical information about the input string (a 'signature') in your hash. For example: lets suppose that 'm' is your input data, H() is your hashing function (say, MD5), and Sig() is a statistical function (it can really be just another hashing algorithm).
This is what's currently recorded:
You can also record the statistical information:
(where '||' means you just concatenate the strings). This means that what the user supplies has to match two different criteria, therefore the input set is much smaller.That should be good enough, but you can get as fancy as you need to by adding more criteria. Eg:
The good thing about this is that on modern unix systems it's not too hard to implement something that will do this.Imagine a Beowulf cluster of US representatives. Never mind... that wouldn't produce much more work than one representative (0 x any number...)
You could generate enough hot air to power the entire world!
The US: a 'world power' indeed :P
I used to run my X session in a vnc server. Then, my 'real' X session would just run a vnc client in full screen mode, which connected to the vnc server. At work (or wherever), I just create a tunnel to the home machine and run a vnc session over that. That was about 4 years or so ago, so I can't remember exactly how to set it up, but it worked reasonably well.
Then I discovered screen and that worked a lot much better for me - after all, I was mostly running console apps anyway (about the only graphical application I use regularly is a web browser).
If an exploit came out for your car, then your car isn't less safe, it's *perceived* to be less safe. The actual implicit 'safeness' of the car remains the same: the vulnerability existed before, and still exists exactly the same now. On the other hand: it *is* less safe because we know more information about it, such that those with ill intent can abuse the safety flaws, instead of not being able to because they don't know about them. I think that this line of thinking can be directly applied to software.
If you think about the second way of looking at it, then you might see what they're getting at: exposing problems provides a greater opportunity for the security flaws of the car/software to be exploited (at least until they're patched). I think that this completely ignores the fact that, as an above poster (c0dedude) said, if we criminalise the discovery of exploits, then only the criminals will know of the exploits (assertion: there will always be criminals). Sure, there *might* probably be *fewer* incidents of the exploit being abused because less people know about them, but sure as hell the software developer or the legitimate users of the software are going to know about it, at least until *after* it happens, and possibly not even then. The finding of faults in the software will be done during forensics - if they can find them at all.
Ken Brown will make lots of money from this book because of the massive free publicity.
No, we'll do it the "Open Source" way and rip it off, DUH!
ohwaitaminute...
However, when I made a conscious effort to start eating raw vegetables with *every* meal (and not just a carrot or so a day), I noticed that I started having fewer headaches, had more energy, and just generally felt all-around healthier. Now, if I don't eat my veggies, I find that those symptoms come right back. Carrots, celery, lettuce, and green peppers are almost always staples in my fridge.
Now see, what's going on here is that you've become addicted to these so-called "healthy" foods and have built up a dependency, as shown by your withdrawal symptoms. The effects of these food items are perceived increase in clarity and energy, and overall "health", exactly as you have described. But we all know the truth: you're addicted.
The way you say make it sound as if the free government services were competing against the private sector. In that case I can see the argument from the private sector.
The way I see this case is that the government is choosing a product from the market that best suits them (ie: cheaper, whatever). That is, they're letting market forces dictate their product descisions. Isn't that capitalism at work - the very thing that SCO reckons linux prevents?
omg, when I waved my mouse over the link I expected the url to show up as something like http://www.microsoft.com/press/linuxsuxks or something...
I'm still waiting for one country to trade in their Get a Free Clue card, and actually ask those of us involved in it for ideas on how to make it work - how to balance legal requirements for privacy and accountability with freedom to express.
why wait for them to ask? maybe we are just reactive? maybe we need to be proactive and go to them?
maybe we need to form a group, and go the the government and actually say something like "We are concerned with this, and we want to work with the govt to come up with some real solution that's not going to be a knee jerk reaction to anything..."?
I can't actually remember anywhere that we have done anything like that. maybe it's worth thinking about? maybe we could get some real response that way
there's an interesting novel dealing with such issues. It's called Metal Fatigue by Sean Williams.
the issues presented in the book raise the question of the impacts to society that such modification have.
for exaple, I can use this technology to repair damage to ones arm so that they can regain the use of that arm. on the other hand, I can use this technology to create your supersoldier.
what you then have to ask yourself is: what kind of impact is this going to have on the individual? For the arm dude, he regains agility. for the supersoldier, does he get a sense of superiority? of somehow being "Better" than everyone else?
what about his commanders? they have access to a better killing machine now. how are the general populacy going to react? how are the modified people going to react?
you haven't created a dude that's just stronger than everyone else, you have created a person that thinks he's stronger/better than everyone else. a deadly concoction if you ask me
we can rebuild him! we have the technology!
Funny, but the Auditor General here in Perth has just completed a 5 year study that concludes that children playing "violent" computer games won't grow up to be any more violent or abusive than kids that don't...