Comment Re:Good. (Score 1) 104
Not to worry, he'd be saved by Mr. Canoe Head.
Not to worry, he'd be saved by Mr. Canoe Head.
The trouble with these things is that they want to "phone home" too much. For energy conservation, Nest talks to a Nest, Inc. server and tells it too much. The info it needs (outside temp, power grid load status) is freely available from read-only web sites. (Given a ZIP code, the National Weather Service site will return info in XML.) But no, it has to talk to the "cloud" and give out personal information. That's totally unnecessary.
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.
BUT THEN HE TRIES FOR A FALSE COROLLARY.
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.
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.
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
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.
When I step on my scale, it tells me if I need to carry an umbrella today (based on the weather forecast it downloaded). Then it sends my weight etc. to my iPhone where it's merged with information from my fitness wristband and my diet tracker. Based on that, I get suggestions like "you've been going to bed a little later than usual. You should catch up." or "drink more water today" or "try to walk this much further than you did yesterday".
I think that's not so shabby.
I have several Teletype machines from the 1926 to 1940 period. All are in good working order. They're completely repairable; it's possible to take one apart down to the individual parts and put it back together. But they're high-maintenance. There are several hundred oiling points on a Model 15 Teletype. There are things that have to be adjusted occasionally, and manuals and tools for doing that. Every few years, the entire machine has to be soaked in solvent to clean off excess oil, then relubricated and adjusted. This is the price of building a complex machine good for a century or more.
(The Model 33 of the minicomputer era is not one of the long-lived machines. This was by design. The Model 35 was the equivalent long-lived, high-maintenance product; the 33 required little mainenance but had a llimited life.)
The problem is C. Programs in all the languages that understand array size, (Pascal, Modula, Ada, Go, Erlang, Eiffel, Haskell, and all the scripting languages) don't have buffer overflow problems.
It's not an overhead problem. That was solved decades ago; compilers can optimize out most subscript checks within inner loops.
I've proposed a way to retrofit array size info to C, but it's a big change to sell. There are many C programmers who think they're so good they don't need subscript checks. Experience demonstrates they are wrong.
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.
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.
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.
One thing I haven't heard discussed is whether affected companies should be notifying their end users about whether they were affected and when it was fixed. I haven't heard from my bank, for example. Where they ever vulnerable? Should I update my password? If they were vulnerable, is it fixed now or would I just be handing an attacker my new password if I were to reset it today?
I wrote up a proposal called Heartbleed headers for communicating this information to site visitors. While I'd like it if everyone picked my idea as the new standard way for doing this, I just wish admins would start using something. We're so close to having a browser plugin be able to tell you "you need to update your password on this site" as you browse. How nice would that be?
They saw diesel electric locomotives replace steam engines in just one decade in 1950s.
The reason was different. Diesels cost about 3x as much as steam locomotives pre-WWII. But by the 1950s, diesel engine manufacturing was a production line process and the price had come down.
The real advantage of diesel over steam was that steam locomotives are incredible maintenance-intensive. Here's daily maintenance. That's what had to be done every day, by a whole crew. That's just daily. Here's 120,000 mile maintenance, done about once a year for a road locomotive. This isn't an oil change; this is a full teardown, boiler replacement, and rebuild.
Electric cars don't have that big an edge over IC engines at this point.
We could send radio signals that far, with the big dish at Arecibo. If they have intelligence, and radio, we can communicate with a 1000-year round trip time. Maybe we should transmit some of the proposed canned messages to other civilizations every month or so.
If there is other intelligent life out there, it looks like they're a very long way away. Too far to talk to round trip, even at light speed. None of the known extra-solar planets within a few light years look promising.
Right. Traditional pneumatics is rather dumb - most of the time it's on/off, with air cylinders pushed up against hard limit stops. Positional control of pneumatic cylinders works fine, but it takes proportional valves, feedback sensors, and a fast control system. Until recently, industrial systems tended not to get that fancy.
I was interested in using pneumatics for running robots back in the 1990s, but the available proportional valves back then were big and expensive. One useful model of muscles is two opposed springs, and a double-ended pneumatic cylinder can do just that. You can change both position and stiffness, separately. You can simulate a spring, and recover energy. Someone did that at CWRU a decade ago, but the mechanics were clunky. Festo does that elegantly with their new kangaroo. Very nice mechanical engineering.
Shadow Robotics has a nice pneumatic robot hand. Shadow has been doing pneumatic flexible actuators for many years, but now they have good controllability.
HOLY MACRO!