Like I just said: I'm talking about when companies use streaming AND use DRM to prevent the users from saving the streams as a file.
The companies could ameliorate this by modifying their apps to allow local caching, OR by removing the DRM from the streams so that people could save the streams themselves.
Of course there are examples of companies that have done the former, I cited Google Play as an example.
Of course you're right that the policy of Hulu and Netflix is the real problem, but the problem is also that it's enforced via DRM which makes it impossible for third parties to write tools that could save the stream to your hard drive. Both the bad policy and the DRM have to exist at the same time for the problem to exist; removing either of those would solve the problem (although fixing their policy would be a better solution).
Hmm, why would it be more useful for music files? The usefulness of this feature is equal to the difference in convenience between caching the content, and streaming it. The larger the file, the greater the difference in convenience -- which, by that logic, would make it more "convenient" for movies than for music files.
I am talking about streaming which is DRMed in a manner that makes it impossible to save the contents as a file. (Normal streams are pretty easy to save as a file.) I probably should have said "DRMed streams" in the article title to make it clearer.
That sounds like it could be right, but Google Play must have made the same calculation at some point, and they went with the conclusion that it was worth it to support downloading and pinning. Every time I'm taking a plane trip, I get content from Google Play and nowhere else for exactly that reason.
But that just makes it seem all the more pointless since other companies (e.g. Google Play) have implemented DRM schemes that *do* allow local savings, and it hasn't killed their business or caused the content providers to come after them.
Well iTunes does but many of the other popular ones do not (e.g. Hulu and Netflix), and those let you consume all the content you want for a monthly fee.
I did say in the article I was using DRM to refer to the DRM that's specifically used on streaming media to make it hard to save as a local file.
That DRM system is crappier than most, but some other systems don't have those particular problems -- Google Play lets me pin a movie to my phone and watch it on a plane without phoning home to make sure I have permission to watch it.
Well when I refer to the "cost" of finding the next bug I'm referring to the estimated average cost, so that factors in the possibility of failure or going over budget or not being the first to find something.
Yes, the bounty program doesn't have to be quite as high as the black market value, because most people would prefer to deal with the software manufacturer than with the black market. Good point, I should have mentioned it.
But regarding this endless hair-splitting of the use of the word "infinite", for heaven's sake, I said in the article, and about ten times since, I don't mean literally infinite. What I mean is, suppose the amount of security bugs that can be found for $100K worth of effort is... "very large". That means there's no point in you, as a white hat, investing $100K worth of effort to find and fix one of those bugs, because if an attacker was going to spend $100K worth of effort to try and find a bug, and the number of such distinct bugs is enormous, then they're probably not going to find the exact same bug that you found, and therefore you haven't increased the attacker's estimated mean time to find a new exploit.
On the other hand, that doesn't change the fact that if a particular bug has been found and released in the wild, obviously you should still plug that one.
Make up your mind how you're going to spell my name...
Anyway, isn't the answer to your first question obviously that Slashdot has decided they want to be not a pure news aggregate, but a news aggregate that occasionally posts original content? When McDonalds put their first chicken burgers on their menu, did people go ballistic saying "What makes you think McDonalds, a beef hamburger joint, is the place to be selling chicken burgers?"
As for the second question, I think the articles meet a high threshold of reaching a counterintuitive or controversial conclusion while proceeding from premises and reasoning steps that individually are hard to argue against. If I just wrote articles that stated a controversial point of view without the supporting argument, I doubt Slashdot would publish them.
The "$10 million" figure is to answer the objection from people who say there's no such thing as an effectively infinite bug threshold.
So I assume your objection is different: there might be infinite bugs at $10 million, but it doesn't matter because nobody would pay that much for an bug. But consider now, is the same possibly true at $1 million? What about $500,000? Because now you're getting within an order of magnitude of what it might be worth on the black market.
Hopefully the infinite bug threshold is not below the black market value of a vulnerability, but the point of the article is that everything is different depending on whether it is or isn't.
As with every action, the question is whether the benefits outweigh the costs. The benefit of these articles is that they give people who find them interesting something to think about (yes, some comments clearly come from people in that category), and the cost is almost zero, because people who don't like them can scroll past them. (If you know you probably won't like the article but you click through and start posting comments anyway, that's not a cost, because it's self-inflicted.)
And I didn't mean that a publicly known vuln should not be fixed because "they'll just find another one". What I meant is that if you privately spend $10K worth of effort to find a vuln that only you know about (as far as you know), but it turns out there are so many distinct vulns that can be found for $10K worth of effort that it's not practical to fix them all, then you might as well not bother fixing that one because it doesn't increase the estimated mean time for the attacker to find a vuln (which might be that one or might be a different one). Obviously that logic doesn't apply to a publicly known vulnerability because that one will be exploited right now unless you patch it.
Yes we'd expect the cost-to-find to steadily increase at the beginning of testing, and, right, you don't know the number of remaining bugs, all you can do is measure how the cost-to-find is increasing.
My point is that there is probably some dollar value at which the cost to find the next vuln would never increase beyond that -- in other words, the Apache web server could never reach a state at which you could not find a new vuln for less than $10 million. And the actual dollar threshold might be much lower than that. That's what I'm calling the infinite bug threshold. The question is whether it's lower than the black market value of an exploit, and if it is, then that means the software can never be made secure.
Which premise do you think is dubious, do you disagree with the premise that an "infinite bug threshold" exists?
In other words, do you think I'm wrong to say that, whatever state the Apache web server reaches (in the real world that we actually live in, not a hypothetical world with infinite time to scrutinize the code), that a new vulnerability could always be found with $10 million worth of effort?
An interesting argument is one that proceeds from premises and reasoning steps that individually are uncontroversial, but taken together, lead to a conclusion that is far from obvious, or even seems wildly counterintuitive -- but which, if you accept the premises and reasoning steps, you have to accept the conclusion as well. The more counterintuitive the conclusion, the more interesting the argument, as long as the premises and reasoning steps are sound. Even if you disagree with the conclusion, the interesting part is to try and identify the premise or reasoning step that you disagree with.
The problem is that many people respond to these arguments simply based on how they "feel" about the conclusion, and that's missing the point.
Congratulations, you're the first person who called me out for saying "infinite number of bugs", where I replied and said "I didn't say literally infinite, just big," and you actually got the point and moved forward:)
Okay, I guess I misunderstood parts of your post, but I still see some issues.
First, you're assuming that the only consideration for people that find security vulnerabilities is money, so that if the potential illicit earnings from exploiting the bug are greater than the bounty, they will exploit the bug. This is definitely not true in practice. Some people just want to do good things. And even for people with no conscience whatsoever, they have to deal with the fact that doing something puts you into a high stress defensive stance where you constantly have to cover your tracks. Most people wouldn't want that kind of lifestyle.
Yes, that's true -- so that introduces a fudge factor into the amount of the bounty, since it doesn't have to be quite as high as the black market value. It can be less, since most people would prefer dealing with the software manufacturer.
Second, you're assuming that the number of bugs found increases linearly with the dollar amount of bug bounties, but my gut instinct is that it is an asymptotic function. Increased bug bounties offer diminishing returns because after a certain point the limiting factor becomes the fact that bugs are really darn hard to find. (Case in point, OpenSSL. Every major tech company uses OpenSSL and several have conducted regular audits of it. Even with all that effort, no one was able to uncover the Heartbleed bug until earlier this year.) So even if Microsoft were to offer $10 million per bug, I don't think they would start finding more bugs than they could fix.
I don't think my conclusion depends on the assumption that the amount of bugs increases linearly with the amount of effort invested. All I'm saying is that it's an increasing function -- the more effort you're willing to spend, the more bugs you can find -- and in fact I was assuming that for some threshold level of effort, the amount of bugs you could find becomes practically infinite. And the critical question is whether that amount is above or below the black market value of a bug.
Well, nobody really knows what would happen if there were a $10 million prize for security bugs, but I suspect that the number of bugs you could find for that effort, really would be effectively unlimited (that is, so large that you couldn't possibly find and patch them all within the time frame before the software became obsolete). Possibly the reason nobody found Heartbleed sooner is that there really is no reward for it comparable to the $10 million -- you get huge professional recognition as a security researcher, but for almost all the rewards that will go to the people who discovered the bug, they're probably not the kind of rewards that most people would choose over $10 million in cash.
All of the people talking as if I had said there were "literally infinite" bugs in a product are missing the point. 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.
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.
Do you think that statement is incorrect? That for $10 million worth of effort, you could always find a new vulnerability in Apache, no matter how many iterations of bug-fixing you've already gone through?
I certainly do. First of all, there are only so many lines of code. Once you hypothetically 'fix' every one of them, you're done.
Well, theoretically yes. 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?
I said in the article, I didn't mean the number of independent bugs that could be found for (say) $10K worth of effort was literally infinite, only that you wouldn't come close to running out, in the time horizon before the software becomes obsolete.
Again, do you think Apache could ever, in practice, reach a state where you couldn't find one more vulnerability in it for $10 million worth of effort? I would say, probably not. That's probably true for some much lower dollar value as well.
I said very clearly in the article, I didn't mean that there are ever literally infinite bugs, only that the number which can be found for (say) $10,000 worth of effort is so large, that you won't come close to running out, in the time horizon before the software becomes obsolete or the point is moot.
Everybody arguing as if I had said the number of bugs is literally infinite is missing the point.
The point of the article is that IF there are finitely many vulns that can be found for a cost below the black-market value of such a vuln, then fixing each one does make the product more secure, and offering a bounty will be a step in that direction.
But IF there are effectively infinitely many vulns that can be found for less than the black market value, then fixing one does not decrease the probability that the attacker will find another one.
Yes this would be a valid concern. So this is a reason why some people might not bother searching for vulnerabilities at all -- they don't want to sell them on the black market, and they don't trust the company to pay them.
But fortunately I don't think that's fatal to the analysis because that just leaves the people left over who are willing to do the work to find vulns. All that matters is that they think the software manufacturer is more trustworthy and more likely to pay than the black-marketeers. Then as long as the prize offered by the software maker is at least equal to what the black market would pay, the researcher would rationally prefer to turn it in to the software manufacturer.
I'm talking about a large number of vulnerabilities that exist in parallel at a given point in time, not ones that exist in series where fixing one vulnerability introduces a new one.
If a large number of vulnerabilities that can be found for $5K, then if you spend $5K of your own effort finding one such vulnerability so that you can fix it, the probability approaches zero that the attacker is spending their effort finding the same vulnerability.
Slashdot Mirror
Like I just said: I'm talking about when companies use streaming AND use DRM to prevent the users from saving the streams as a file.
The companies could ameliorate this by modifying their apps to allow local caching, OR by removing the DRM from the streams so that people could save the streams themselves.
Of course there are examples of companies that have done the former, I cited Google Play as an example.
Of course you're right that the policy of Hulu and Netflix is the real problem, but the problem is also that it's enforced via DRM which makes it impossible for third parties to write tools that could save the stream to your hard drive. Both the bad policy and the DRM have to exist at the same time for the problem to exist; removing either of those would solve the problem (although fixing their policy would be a better solution).
Hmm, why would it be more useful for music files? The usefulness of this feature is equal to the difference in convenience between caching the content, and streaming it. The larger the file, the greater the difference in convenience -- which, by that logic, would make it more "convenient" for movies than for music files.
I am talking about streaming which is DRMed in a manner that makes it impossible to save the contents as a file. (Normal streams are pretty easy to save as a file.) I probably should have said "DRMed streams" in the article title to make it clearer.
That sounds like it could be right, but Google Play must have made the same calculation at some point, and they went with the conclusion that it was worth it to support downloading and pinning. Every time I'm taking a plane trip, I get content from Google Play and nowhere else for exactly that reason.
OK yes, that's a more accurate way of putting it.
But that just makes it seem all the more pointless since other companies (e.g. Google Play) have implemented DRM schemes that *do* allow local savings, and it hasn't killed their business or caused the content providers to come after them.
Well iTunes does but many of the other popular ones do not (e.g. Hulu and Netflix), and those let you consume all the content you want for a monthly fee.
I did say in the article I was using DRM to refer to the DRM that's specifically used on streaming media to make it hard to save as a local file.
I like turtles!!!
That DRM system is crappier than most, but some other systems don't have those particular problems -- Google Play lets me pin a movie to my phone and watch it on a plane without phoning home to make sure I have permission to watch it.
Well when I refer to the "cost" of finding the next bug I'm referring to the estimated average cost, so that factors in the possibility of failure or going over budget or not being the first to find something.
Yes, the bounty program doesn't have to be quite as high as the black market value, because most people would prefer to deal with the software manufacturer than with the black market. Good point, I should have mentioned it.
But regarding this endless hair-splitting of the use of the word "infinite", for heaven's sake, I said in the article, and about ten times since, I don't mean literally infinite. What I mean is, suppose the amount of security bugs that can be found for $100K worth of effort is... "very large". That means there's no point in you, as a white hat, investing $100K worth of effort to find and fix one of those bugs, because if an attacker was going to spend $100K worth of effort to try and find a bug, and the number of such distinct bugs is enormous, then they're probably not going to find the exact same bug that you found, and therefore you haven't increased the attacker's estimated mean time to find a new exploit.
On the other hand, that doesn't change the fact that if a particular bug has been found and released in the wild, obviously you should still plug that one.
Make up your mind how you're going to spell my name...
Anyway, isn't the answer to your first question obviously that Slashdot has decided they want to be not a pure news aggregate, but a news aggregate that occasionally posts original content? When McDonalds put their first chicken burgers on their menu, did people go ballistic saying "What makes you think McDonalds, a beef hamburger joint, is the place to be selling chicken burgers?"
As for the second question, I think the articles meet a high threshold of reaching a counterintuitive or controversial conclusion while proceeding from premises and reasoning steps that individually are hard to argue against. If I just wrote articles that stated a controversial point of view without the supporting argument, I doubt Slashdot would publish them.
The "$10 million" figure is to answer the objection from people who say there's no such thing as an effectively infinite bug threshold.
So I assume your objection is different: there might be infinite bugs at $10 million, but it doesn't matter because nobody would pay that much for an bug. But consider now, is the same possibly true at $1 million? What about $500,000? Because now you're getting within an order of magnitude of what it might be worth on the black market.
Hopefully the infinite bug threshold is not below the black market value of a vulnerability, but the point of the article is that everything is different depending on whether it is or isn't.
As with every action, the question is whether the benefits outweigh the costs. The benefit of these articles is that they give people who find them interesting something to think about (yes, some comments clearly come from people in that category), and the cost is almost zero, because people who don't like them can scroll past them. (If you know you probably won't like the article but you click through and start posting comments anyway, that's not a cost, because it's self-inflicted.)
And I didn't mean that a publicly known vuln should not be fixed because "they'll just find another one". What I meant is that if you privately spend $10K worth of effort to find a vuln that only you know about (as far as you know), but it turns out there are so many distinct vulns that can be found for $10K worth of effort that it's not practical to fix them all, then you might as well not bother fixing that one because it doesn't increase the estimated mean time for the attacker to find a vuln (which might be that one or might be a different one). Obviously that logic doesn't apply to a publicly known vulnerability because that one will be exploited right now unless you patch it.
Yes we'd expect the cost-to-find to steadily increase at the beginning of testing, and, right, you don't know the number of remaining bugs, all you can do is measure how the cost-to-find is increasing.
My point is that there is probably some dollar value at which the cost to find the next vuln would never increase beyond that -- in other words, the Apache web server could never reach a state at which you could not find a new vuln for less than $10 million. And the actual dollar threshold might be much lower than that. That's what I'm calling the infinite bug threshold. The question is whether it's lower than the black market value of an exploit, and if it is, then that means the software can never be made secure.
Which premise do you think is dubious, do you disagree with the premise that an "infinite bug threshold" exists?
In other words, do you think I'm wrong to say that, whatever state the Apache web server reaches (in the real world that we actually live in, not a hypothetical world with infinite time to scrutinize the code), that a new vulnerability could always be found with $10 million worth of effort?
An interesting argument is one that proceeds from premises and reasoning steps that individually are uncontroversial, but taken together, lead to a conclusion that is far from obvious, or even seems wildly counterintuitive -- but which, if you accept the premises and reasoning steps, you have to accept the conclusion as well. The more counterintuitive the conclusion, the more interesting the argument, as long as the premises and reasoning steps are sound. Even if you disagree with the conclusion, the interesting part is to try and identify the premise or reasoning step that you disagree with.
The problem is that many people respond to these arguments simply based on how they "feel" about the conclusion, and that's missing the point.
Okay, I guess I misunderstood parts of your post, but I still see some issues.
First, you're assuming that the only consideration for people that find security vulnerabilities is money, so that if the potential illicit earnings from exploiting the bug are greater than the bounty, they will exploit the bug. This is definitely not true in practice. Some people just want to do good things. And even for people with no conscience whatsoever, they have to deal with the fact that doing something puts you into a high stress defensive stance where you constantly have to cover your tracks. Most people wouldn't want that kind of lifestyle.
Yes, that's true -- so that introduces a fudge factor into the amount of the bounty, since it doesn't have to be quite as high as the black market value. It can be less, since most people would prefer dealing with the software manufacturer.
Second, you're assuming that the number of bugs found increases linearly with the dollar amount of bug bounties, but my gut instinct is that it is an asymptotic function. Increased bug bounties offer diminishing returns because after a certain point the limiting factor becomes the fact that bugs are really darn hard to find. (Case in point, OpenSSL. Every major tech company uses OpenSSL and several have conducted regular audits of it. Even with all that effort, no one was able to uncover the Heartbleed bug until earlier this year.) So even if Microsoft were to offer $10 million per bug, I don't think they would start finding more bugs than they could fix.
I don't think my conclusion depends on the assumption that the amount of bugs increases linearly with the amount of effort invested. All I'm saying is that it's an increasing function -- the more effort you're willing to spend, the more bugs you can find -- and in fact I was assuming that for some threshold level of effort, the amount of bugs you could find becomes practically infinite. And the critical question is whether that amount is above or below the black market value of a bug.
Well, nobody really knows what would happen if there were a $10 million prize for security bugs, but I suspect that the number of bugs you could find for that effort, really would be effectively unlimited (that is, so large that you couldn't possibly find and patch them all within the time frame before the software became obsolete). Possibly the reason nobody found Heartbleed sooner is that there really is no reward for it comparable to the $10 million -- you get huge professional recognition as a security researcher, but for almost all the rewards that will go to the people who discovered the bug, they're probably not the kind of rewards that most people would choose over $10 million in cash.
All of the people talking as if I had said there were "literally infinite" bugs in a product are missing the point. 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.
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.
Do you think that statement is incorrect? That for $10 million worth of effort, you could always find a new vulnerability in Apache, no matter how many iterations of bug-fixing you've already gone through?
I certainly do. First of all, there are only so many lines of code. Once you hypothetically 'fix' every one of them, you're done.
Well, theoretically yes. 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?
I said in the article, I didn't mean the number of independent bugs that could be found for (say) $10K worth of effort was literally infinite, only that you wouldn't come close to running out, in the time horizon before the software becomes obsolete.
Again, do you think Apache could ever, in practice, reach a state where you couldn't find one more vulnerability in it for $10 million worth of effort? I would say, probably not. That's probably true for some much lower dollar value as well.
I said very clearly in the article, I didn't mean that there are ever literally infinite bugs, only that the number which can be found for (say) $10,000 worth of effort is so large, that you won't come close to running out, in the time horizon before the software becomes obsolete or the point is moot.
Everybody arguing as if I had said the number of bugs is literally infinite is missing the point.
The point of the article is that IF there are finitely many vulns that can be found for a cost below the black-market value of such a vuln, then fixing each one does make the product more secure, and offering a bounty will be a step in that direction.
But IF there are effectively infinitely many vulns that can be found for less than the black market value, then fixing one does not decrease the probability that the attacker will find another one.
For the third time: Is there a statement in the article, or a step in the reasoning, that you believe is incorrect?
If you cannot cite an example this time then I'm going to assume you don't have one.
Yes this would be a valid concern. So this is a reason why some people might not bother searching for vulnerabilities at all -- they don't want to sell them on the black market, and they don't trust the company to pay them.
But fortunately I don't think that's fatal to the analysis because that just leaves the people left over who are willing to do the work to find vulns. All that matters is that they think the software manufacturer is more trustworthy and more likely to pay than the black-marketeers. Then as long as the prize offered by the software maker is at least equal to what the black market would pay, the researcher would rationally prefer to turn it in to the software manufacturer.
I'm talking about a large number of vulnerabilities that exist in parallel at a given point in time, not ones that exist in series where fixing one vulnerability introduces a new one.
If a large number of vulnerabilities that can be found for $5K, then if you spend $5K of your own effort finding one such vulnerability so that you can fix it, the probability approaches zero that the attacker is spending their effort finding the same vulnerability.