Forgot your password?

Comment: Re:Ivy League Schools (Score 1) 11

by ShieldW0lf (#46792269) Attached to: Minerva CEO Details His High-Tech Plan To Disrupt Universities

The Ivy League was basically a formal gentleman's agreement (you know, back from the good old days where they banned women and blacks from campus and had strict quotas on Jews) that they would mutually agree to be terrible at sports in order to maintain high academic standards.

Everyone who attends an Ivy League school to play sports is someone who would have been a serious consideration for admission without their athletic ability.

Of course they're going to be terrible at sports. They don't have any black people on their team!

Comment: Re:I hate personal definitions (Score 1) 166

by ShieldW0lf (#46792191) Attached to: 'Thermoelectrics' Could One Day Power Cars

Dude, you're the worst sort of person to argue with. You've demonstrated poor reading comprehension and a willingness to hand-wave away the distinction between similar words if you don't think they are relevant to you or serve your position. You seriously make me wonder why I even bother trying to express myself precisely

I never used the word explosion. I used the word detonation. I contrasted it with the deflagration that occurs in internal combustion engines like we see in cars.

A detonation occurs when the shock wave expanding out of the reaction zone compresses the unburnt fuel ahead of the wave, and the compressive heating raises the temperature in the unburnt fuel above it's autoignition temperature.

10 m/s is well below the threshold. Try 2000 m/s.

Detonation produces a more efficient combustion than deflagration, gives higher yields, and generates more kinetic force relative to the thermal energy released. It's a whole different kettle of fish.

Comment: Re:PS: how do you think it gets on the distro mirr (Score 1) 151

by Anonymous Brave Guy (#46791395) Attached to: Heartbleed Sparks 'Responsible' Disclosure Debate

I think there is a qualitative difference between notifying large end users like Facebook in advance, and notifying people in the distribution system for a general release. It's the former that inherently means the people who aren't large end users with privileged access get left exposed for longer than necessary, and that's what I'm objecting to.

Comment: Re:Wrong math. 2 years of vulnerability. (Score 1) 151

by Anonymous Brave Guy (#46791385) Attached to: Heartbleed Sparks 'Responsible' Disclosure Debate

You're latching onto this specific case, perhaps because you have some connection to it, but I'm talking about the general principle here. In general, it is not unreasonable to assume that if a vulnerability has been found by two parties in rapid succession, there may be a common factor involved, which may mean that other parties will also find it in the same time frame, and that an extra day may therefore be very significant.

Obviously most serious security bugs don't sit there for years, then have two groups discover them at almost the same time, as seems to have happened in this case, and need half the known Internet to update their systems as a precaution because no-one really knows whether they've been damaged by the vulnerability at any time over the past couple of years.

ROTFL. Yep, large corporate bureaucracies, they ALWAYS do exactly the right thing, in a matter of hours.

If it's that funny to you, why are you defending giving them a day of advanced warning? Some of us did have a patch rolled out within a couple of hours of the public announcement, but presumably we could have had the patch rolled out a day earlier in the alternative situation. Once again, in this case, one day in two years obviously isn't that significant as we're all going to have to assume keys were compromised and set up new ones anyway. But if this was something that only got committed three days ago, it's a different story.

Comment: Re:Not that good (Score 1) 151

by Anonymous Brave Guy (#46791359) Attached to: Heartbleed Sparks 'Responsible' Disclosure Debate

Since "people" cannot be negative, by necessity (dev team) + (other people) >= (dev team)

You're still assuming that the dev teams, or to be more precise the parts of the dev teams who will actively review new code, are the same size. That isn't necessarily true at all, so the "provided everything else is equal" part of your last sentence is the problem here.

Comment: Re:The power of EULAs only goes so far (Score 1) 210

by Anonymous Brave Guy (#46791343) Attached to: Click Like? You May Have Given Up the Right To Sue

My point is there's no "might" about it - as long as the arbitration clause applies to both parties and the arbiter is a neutral one, it's a perfectly legal and enforceable clause...

It's still highly uncertain whether a court would find a contract to exist at all under these conditions.

Even if it does, you can always go to court and argue for your right to be there because the other guy's term about arbitration is unenforceable for whatever reason. The court might disagree and send you back to arbitration, but they won't stop you coming in the door in the first place.

Comment: Re:When did slashdot become a blog for Bennett? (Score 1) 195

by khasim (#46791205) Attached to: Bug Bounties Don't Help If Bugs Never Run Out

Except he did not stop there. That's the problem. Allow me to re-state his original premise.

For a currency "X" there exists an amount "Y" at which (or below) no one will sell accurate bug reports to you.

When X = "pennies" and Y = "2" you can see how it works. Would you spend your time looking for bugs and reporting them for a possible payout of two cents per report? So at that point I can agree with him.


For a currency "X" there exists an amount "Z" at which (or above) people will sell accurate bug reports to you.

He uses X = "dollars" and Z = "10 million" there.

The reason it is a false corollary is that it depends upon a bug's existence being based upon the amount offered to find it.

Comment: No, they are not. (Score 1) 195

by khasim (#46790893) Attached to: Bug Bounties Don't Help If Bugs Never Run Out

All of the people talking as if I had said there were "literally infinite" bugs in a product are missing the point.

No. They understand and they are explaining to YOU where YOU are wrong.

I said, very clearly, that of course the number of bugs is not literally infinite, but I was considering the case where there are so many bugs which can be found for $X worth of effort, that it's unrealistic to find and fix them all in the time frame before the product becomes obsolete anyway.

And that is where you are wrong. YOU are claiming that a very specific HYPOTHETICAL situation is same as the general ACTUAL situation.

Your HYPOTHETICAL situation is 100% divorced from the ACTUAL situation.

In the ACTUAL situation there are a finite number of buffer overflow bugs in any specific program and those buffer overflow bugs can be found and fixed WITHOUT another buffer overflow bug appearing. And it is EASY to find the MAXIMUM number of buffer overflow bugs by searching the source code for every instance of a buffer being used.

Finite AND countable AND fixable.

The fact that there are dozens of people responding as if I had said "literally infinitely many bugs" does not make their point any more valid.

No. They are pointing out that YOU have made that assumption even though YOU keep denying it.

Because once you admit that the number of buffer overflow bugs is finite AND countable then there exists a point where they can ALL be fixed. And you keep denying that that is possible.

Comment: Re:Bennett's Ego (Score 1) 195

by khasim (#46790713) Attached to: Bug Bounties Don't Help If Bugs Never Run Out

Well, theoretically yes.

"Theoretically". Got it.

But do you think that Apache could ever reach a state in practice, in the world we actually live in, where you couldn't find a new vulnerability in it for $10 million worth of effort?

Emphasis added.

So now you're conflating a real-world situation with a hypothetical situation ... no. You do not get to mix real-world and hypotheticals in the same sentence. No one is offering $10 million and no one is likely to offer $10 million.

IF someone would offer $10 million for buffer overflow bugs in Apache then a lot of people would comb through the code and check each instance of a buffer for an overflow bug. All the buffer overflow bugs would be found.

After that, finding ANOTHER buffer overflow bug would not be possible IN THAT CODE BASE. No matter how much money was offered. Because all the instances should have been checked and identified.

Someone would have to submit code that included a NEW buffer overflow bug in order for a NEW buffer overflow bug to be discovered.

No matter how much money was being offered. No "theoretically" about it. It's Computer SCIENCE.

Comment: Re:That's where you are wrong. (Score 1) 195

by khasim (#46789043) Attached to: Bug Bounties Don't Help If Bugs Never Run Out

Do you really believe that if you offered a $10 million prize to anyone who could find a vulnerability in the Apache web server, that you would reach the point where people weren't finding and reporting new ones...

From your inclusion of "really believe" I'd say that your question was rhetorical.

And wrong.

At $10 million per buffer overflow? Yes. There would be a finite number of buffer overflows that would be found and fixed.

At $10 million per X category of bug? Yes. There would be a finite number X's that would be found and fixed.

Therefore, unless you assume an infinite number of categories of bugs, all the bugs would eventually be fixed.

Because the code base comprises a finite number of bits and there is a finite number of ways that those bits can be run.

Comment: That's where you are wrong. (Score 1) 195

by khasim (#46788717) Attached to: Bug Bounties Don't Help If Bugs Never Run Out

My point is that if there are (effectively) infinitely many bugs...

No need to read any further because that is an incorrect assumption.

There cannot be an infinite number of bugs (effectively or otherwise) because there is not an infinite about of code NOR an infinite number of ways to run the finite amount of code.

From TFA:

(He confirmed to me afterwards that in his estimation, once the manufacturer had fixed that vulnerability, he figured his same team could have found another one with the same amount of effort.)

Then he was wrong as well.

There are a finite number of times that buffers are used in that code base. Therefore there are a finite number of times that buffers could be overflowed. If someone went through the code and checked each instance and ensured that an overflow situation was not possible then it would not be possible.

"Infinite" does not mean what you think it does.

Comment: Re:Bennett's Ego (Score 0) 195

by khasim (#46788573) Attached to: Bug Bounties Don't Help If Bugs Never Run Out

Is there a statement in the article that you think is incorrect?

You missed the point of the post that you are replying to. But since you asked ...

You can visualize it even more starkly this way: A stranger approaches a company like Microsoft holding two envelopes, one containing $1,000 cash, and the other containing an IE security vulnerability which hasn't yet been discovered in the wild, and asks Microsoft to pick one envelope.

That makes no sense. Why would a security-researcher offer to pay MICROSOFT for NOTHING?

Microsoft should be paying the security-researcher.

It would sound short-sighted and irresponsible for Microsoft to pick the envelope containing the cash â" but when Microsoft declines to offer a $1,000 cash prize for vulnerabilities, it's exactly like choosing the envelope with the $1,000.

Wrong again.

Not PAYING $1,000 is NOT the same as getting an ADDITIONAL $1,000.

If I have $1,000 and I do not buy something for $1,000 I still have $1,000. But if someone gives me an envelope with $1,000 then I have TWO THOUSAND DOLLARS.

You might argue that it's "not exactly the same" because Microsoft's hypothetical $1,000 prize program would be on offer for bugs which haven't been found yet, but I'd argue that's a distinction without a difference.

No. It's wrong because in your example Microsoft ends up with an ADDITIONAL $1,000 from a security-researcher.

Comment: Re:Not that good (Score 1) 151

by Anonymous Brave Guy (#46788117) Attached to: Heartbleed Sparks 'Responsible' Disclosure Debate

However, no matter how you look at it, the number of people who actually do will always be equal or higher than for closed source software.

Why? I see little evidence that this is happening in general.

Most established OSS projects seem to require no more than one or two reviewers to approve a patch before it goes in, and then there is no guarantee that anyone will ever look at that code again later.

How does that guarantee that more experts will review a given piece of security code than in a proprietary, closed-source, locked-up development organisation that also has mandatory code reviews?