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 -- in the time horizon before that version of the software becomes obsolete and the whole question becomes moot anyway?
I believe the distinction is that scarcity can drive up the price of something but usually not it's value (to you). The price is where the supply and demand curves meet; you buy the good if it value to you is greater than the market price, and if its value to you is greater than the market price, that's just pure benefit to you (the "consumer surplus").
So, you place a certain amount of value on being able to break into Apache webservers. If existing vulnerabilities get found and fixed, that will, indeed, increase the price of finding the next one, but it won't actually increase its value to you. In the case where eventually all of the bugs get found and fixed that are below the black-market value of an exploit (black market value is less than infinite bug threshold), that doesn't increase the value to you of an exploit; it just means at that point, it's no longer worth your time to find an exploit because the cost of the next one will be greater than the black market value.
Good point, someone else mentioned this and I'll just copy and paste what I wrote here:
Right, I forgot to mention something: To prevent double-use like this, a company should say that you don't get paid until they've fixed the bug and issued a patch for it in their software, all without the exploit ever being spotted in the wild. (If someone else finds your vulnerability and exploits it in the wild, that's just bad luck. So to incentivize researchers, Microsoft might have to increase the prize money proportionally, to make up for the fact that sometimes people won't get paid because their exploits were found by someone else.) This incentivizes people to report bugs and not release them to the black market as well.
Well yes, if eventually you run out of bugs that can be found with less than $10K worth of effort and $10K is the black-market value of the exploit, then that is the case where the black-market value is below the infinite bug threshold, and the product can be made secure, and as you said, black hats will move on to something else. That was my point:)
Which part of it doesn't make sense to you? That if there are effectively infinitely many remote-root vulnerabilities that can be found for $5,000 worth of effort, and the black market value of such a vulnerability is $10,000, then finding and fixing one of those $5K-vulnerabilities will not affect the expected amount of time that it takes the black hat attacker to find one themselves when they start looking?
Except this analysis is wrong and that's what happens if you try and take shortcuts. It doesn't matter whether there is a "very large number of serious security holes", it matters if there is a very large number of serious security holes that can be found for a cost which is less than the black-market value of the security hole.
Yes, I'm sure the article could have been made shorter.
The number of bugs are not limitless, they are very much a finite thing.
That's true -- but I did say,
Obviously the amount of vulnerabilities is not really infinite — you can only do finitely many things to a product in a finite amount of time, after all — but suppose it's so close to infinite as to make no difference, because the manufacturer would never be able to fix all the vulnerabilities that could be found for that amount of effort. I'm sure that $10 million worth of effort, paid to the right people, will always find you a new security vulnerability in the Apache web server; the same is probably true for some dollar number much lower than that, and you could call that the "infinite bug threshold".
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?
The benefit to the company is not limited to closing that single bug. When someone reports one bug, you likely are learning a new method and/or way of thinking in regards to the procedure/module/whatever is involved. One "reported" bug could likely make many dozens or more other bugs readily apparent in your code.
It also teaches your organization how to avoid that bug in the future. How many bugs were in the wild, being used by blackhats for YEARS through multiple iterations of a software package before being caught?
Also, you get to find the mistake in the code and, if you're managing your code correctly, you will know who made the mistake. So you can coach if it was something that should have been caught.
And lastly, it solidifies your place in the market as a leader. People study your code intently, use it more, get more involved. The more people involved, the bigger your talent pool, the more industry respect you have, and as a result the more people will look to you as a company that cares about the stability and long term viability of your product.
I think all of that is true but doesn't negate the argument. Those are all great reasons to incentivize people to find bugs in your product. But if the state of the product is such that in practice it will always be possible to find another vulnerability for $50,000 worth of effort, and the vulnerability is worth $100,000 on the black market, someone will still find another vulnerability and exploit it.
First, bugs in a given program are not infinite in number. By definition. Because the code itself is finite. Finite code cannot have infinite bugs.
I agree... I did wrote, "Obviously the amount of vulnerabilities is not really infinite — you can only do finitely many things to a product in a finite amount of time, after all — but suppose it's so close to infinite as to make no difference, because the manufacturer would never be able to fix all the vulnerabilities that could be found for that amount of effort."
Also, due to the nature of code and how it is created, patching one bug usually also takes care of many others. If you have a buffer overflow problem in your input routine, you need only patch it once, in the routine. Not everywhere that routine is being called.
Right, I also said, "I'm hand-waving over some details here, such as the disputes over whether two different bugs are really considered "distinct," or the fact that once you've found one vulnerability, the cost of finding other closely related vulnerabilities in the same area of the product, often goes way down. But I don't think these complications negate the argument."
In fact I agree with everything you said, it just sounds like you're reaching the same conclusion that I did. Once you're done with in-house bug finding, offer a prize close to the black market value of an exploit in the software. If there are finitely many bugs in that range -- as you said, "You will usually only get a few to deal with before it gets quiet" -- then the prize will sweep them up.
Perhaps I should have emphasized: You don't have to start your bug-fixing by offering a prize, you can find as many of them as possible in-house, and from outsiders who report the easy bugs for free. You could even save money by starting with a lower prize, and then ramping it up slowly. (However, this runs the risk that someone might find a valuable bug early on, but keep it secret waiting for the prize money to go up. If they do this, they run the risk that someone else will find the same bug and claim the prize money and then the original discoverer gets nothing. But somebody still might try this. So that's a downside of slowly increasing the prize money.) As long as you end by offering a prize proportional to the black-market value of the vulnerability.
My point is that if there are (effectively) infinitely many bugs below the black-market value threshold, then the software isn't any less secure because you didn't fix a bug -- because you haven't changed the amount of effort it would take for the attacker to find their next vulnerability.
There aren't infinitely many criminals; crime rates are lower than they would be if we didn't arrest or prosecute criminals, because the population of criminals is finite and in fact small enough that our policing and sentencing policies can make a dent in it. (If there really were infinitely many criminals, then indeed it would be pointless to arrest or prosecute them, but there aren't.)
The analysis only applies to similar classes of vulnerabilities. If you find a remote root exploit in Apache with $5,000 worth of effort, but it turns out there are an effectively infinite number of remote root exploits that can also be found with $5,000 worth of effort, then in fact it is pointless to fix it since that is well below the black-market value of such an exploit, and new ones will never stop being found. But it's irrelevant if there are other far less serious bugs.
Paying people to find bugs and report them responsibly does give those people an incentive to not do something worse with them.
Right, I forgot to mention something: To prevent double-use like this, a company should say that you don't get paid until they've fixed the bug and issued a patch for it in their software, all without the exploit ever being spotted in the wild. (If someone else finds your vulnerability and exploits it in the wild, that's just bad luck. So to incentivize researchers, Microsoft might have to increase the prize money proportionally, to make up for the fact that sometimes people won't get paid because their exploits were found by someone else.) This incentivizes people to report bugs and not release them to the black market as well.
Yeah, I think $1,000 is way too low, I just used it as a sample number.
I think all that matters is that the dollar number matches the black-market value. Then it doesn't matter whether most people would find the effective hourly rate "insulting"; all that matters is that anybody who does find an exploit will turn it in to the company rather than selling it on the black market or exploiting it themselves.
Interesting idea -- what kind of questions did you have in mind for a survey like that?
Part of my point was that people don't realize how inefficient the marketplace for ideas (and intellectual property generally) actually is, so I'm not sure what a survey should ask if I'm writing about a problem people aren't even aware of.
That's the conclusion. The article is the argument to support the conclusion.
There is a summary at the top: "If you read no further, use either the BestParking or ParkMe app to search all nearby parking garages for the cheapest spot, based on the time you're arriving and leaving. I'm interested in the question of why so few people know about these apps, how is it that they've been partially crowded out by other 'parking apps' that are much less useful, and why our marketplace for ideas and intellectual properly is still so inefficient."
That's two sentences, not a single sentence. Sorry.
The second sentence is "I'm interested in the question of why so few people know about these apps, how is it that they've been partially crowded out by other 'parking apps' that are much less useful, and why our marketplace for ideas and intellectual properly is still so inefficient." That's the conclusion; the example with the parking apps is the supporting argument. (I never called the online survey takers my "friends"; I said that I did two surveys, an informal poll of my friends and then a survey on Mechanical Turk.)
Agreed, the app should tell you if a garage is full. I don't know how easy it would be for an app developer to incorporate that though.
How often are garages full, anyway? I hardly ever see them full in Seattle, and I suspect the reason is that if a garage frequently fills up to capacity at any recurring time or under any foreseeable circumstance, the garage owner will realize that they can raise the price during that time or under that circumstance, and the garage will go back to not usually being full.
I'm not saying it's wasteful from the company's point of view; they spend money on marketing because it works.
I'm saying it's wasteful from an overall societal point of view, because if two companies spend money just trying to jostle each other out of the top spot on Google, the net gain will be zero. If they spent the same effort improving their products, and then the overall product quality determined their ranking in an information source like Google, the benefits would accrue to consumers.
Bennett, I like all of your stuff and this is well-written but...
Troll! Get him, boys!
These apps are just going to increase mass neurosis. We don't need our heads filled with this crap. We need to spend more time thinking about important issues, not the trivia.
I think the more important issue is the general inefficiency in the marketplace for apps (as well as ideas and intellectual property in general). That was my main point. I wouldn't have written the article just to tell people about the parking apps, although I hope some people find that useful.
Let me address your objections separately: (1) that you think making it easy to get to Burning Man would lead people to come dangerously unprepared; and (2) that letting people get there with to little effort would ruin the culture.
Regarding (1), I did say, "These points should be taken in conjunction with a more comprehensive guide to preparing and packing; I'm not writing a full guide to getting ready for Burning Man. These just happen to be the points where I wasted the most time going down the wrong path during preparation, taking advice too literally from the BurningMan.com website and/or grizzled veterans who thought that you honor the event's heritage by doing things the hard way, before realizing there was a much easier option." I think a reasonable person could have interpreted that to mean they should read elsewhere for safety tips.
But let's say it's not inconceivable that by giving people an easy way, I encouraged some people to come who were less prepared. On the other hand, if you steer people towards the hard way of doing things (driving there from Louisiana, bringing a bike on the back of your car), that has safety consequences too. Driving that distance, you might have an accident, your car might break down in the heat, etc. Your own bike might be in less good shape than you think, and might cause an accident at BM or fall apart leaving you to make a long and strenuous walk back to camp.
A lot of those incidents could be avoided by people using the shortcuts I recommended. Those incidents, including safety hazards, are a cost of doing things the hard way, and I think it's a fallacy not to count them because either (a) they happen outside the gates of BRC or (b) people see a bike break or cause an accident and it never even occurs to them to think that it could have been avoided by steering that person towards a rental bike.
As for (2) the culture, I don't know of any camps that let you just "pay and show up". They're usually running a theme and require you to contribute a certain number of hours towards participating in the theme, immersing you in the aspect of culture that they are contributing to Burning Man.
Perhaps Burning Man could pre-emptively disallow "motel" camps that allow spots to the general public where you just "pay and show up". Presumably that would alleviate some of your concerns about pure tourists. But everybody has to start as a first-timer, and if a camp requires first-timers to spend time contributing to the camp project -- well, what else would you have them do?
And no, I never once thought either of these articles would ingratiate myself in the existing Burning Man community. On the contrary, as I said one of the subtexts was a critique of communities that won't give straightforward, helpful information to outsiders because they intentionally want to make things difficult for them. It's not just directions on how to get to Burning Man. Most directions, of all kinds, in all categories, suck, in the sense that you can tell the author did not, even once, show them to an outsider and say, "Read through these directions, and if there's any place where you get stuck or where there's something missing, tell me and I'll fix it." This shows a certain contempt for people who are outside the privileged community of insiders.
Most people have not been saying that anything in the original article was actually wrong; mostly I've been getting complaints that the advice makes it too easy for "tourists" to get there. Is there anything in it that you think is incorrect? (Re-reading it now, I probably should have emphasized to try and camp with friends before creating a "Burner Resume" and trying to get matched with a camp, but I figured that would be obvious to most people -- first try and find friends who are going, if you can. But even then, what's wrong with the "Burner Resume" approach? You said "That's not how you do it." Why not? You create a resume, you get matched with a camp, you pay them dues, you save some hassle and they come out ahead -- what's the problem? Unless you're still objecting to the fact that I'm making it "too easy".)
By contrast, the Survival Guide is wrong insofar as it tells you that it's highly recommended to bring your own bike, instead of mentioning the bike rental option, which is much more convenient for people who are flying and taking the Burner Express.
For heaven's sake, I just realized that last year's Survival Guide, in the section "Getting To And From Black Rock City", doesn't even mention Burner Express. I know you're not thrilled about the Sparkle Pony Express, but it's run by the official Burning Man corp. No, I would not call the Survival Guide a completely up-to-date source of the most useful information.
I'm aware of the fact that my original article sounds written someone who has only been to Burning Man once. But it still contains information that is missing from the Survival Guide and that none of the veterans told me when I asked them, but that I think is useful. In a way, that's one of the intended subtexts of the article: that a lot of BM veterans are so unhelpful to outsiders, that here I am having only been one time, and I'm still giving people more useful information than they would get from talking to a lot of the old-timers.
If you think I'm wrong, then again: Do you know of any written preparation guide for first-timers that is accurate and reasonably complete? (At minimum it should mention the Burner Express and the on-playa bike rental option.)
Slashdot Mirror
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 -- in the time horizon before that version of the software becomes obsolete and the whole question becomes moot anyway?
I believe the distinction is that scarcity can drive up the price of something but usually not it's value (to you). The price is where the supply and demand curves meet; you buy the good if it value to you is greater than the market price, and if its value to you is greater than the market price, that's just pure benefit to you (the "consumer surplus").
So, you place a certain amount of value on being able to break into Apache webservers. If existing vulnerabilities get found and fixed, that will, indeed, increase the price of finding the next one, but it won't actually increase its value to you. In the case where eventually all of the bugs get found and fixed that are below the black-market value of an exploit (black market value is less than infinite bug threshold), that doesn't increase the value to you of an exploit; it just means at that point, it's no longer worth your time to find an exploit because the cost of the next one will be greater than the black market value.
Good point, someone else mentioned this and I'll just copy and paste what I wrote here:
Right, I forgot to mention something: To prevent double-use like this, a company should say that you don't get paid until they've fixed the bug and issued a patch for it in their software, all without the exploit ever being spotted in the wild. (If someone else finds your vulnerability and exploits it in the wild, that's just bad luck. So to incentivize researchers, Microsoft might have to increase the prize money proportionally, to make up for the fact that sometimes people won't get paid because their exploits were found by someone else.) This incentivizes people to report bugs and not release them to the black market as well.
Well yes, if eventually you run out of bugs that can be found with less than $10K worth of effort and $10K is the black-market value of the exploit, then that is the case where the black-market value is below the infinite bug threshold, and the product can be made secure, and as you said, black hats will move on to something else. That was my point :)
Which part of it doesn't make sense to you? That if there are effectively infinitely many remote-root vulnerabilities that can be found for $5,000 worth of effort, and the black market value of such a vulnerability is $10,000, then finding and fixing one of those $5K-vulnerabilities will not affect the expected amount of time that it takes the black hat attacker to find one themselves when they start looking?
Except this analysis is wrong and that's what happens if you try and take shortcuts. It doesn't matter whether there is a "very large number of serious security holes", it matters if there is a very large number of serious security holes that can be found for a cost which is less than the black-market value of the security hole.
Yes, I'm sure the article could have been made shorter.
The number of bugs are not limitless, they are very much a finite thing.
That's true -- but I did say,
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?
The benefit to the company is not limited to closing that single bug. When someone reports one bug, you likely are learning a new method and/or way of thinking in regards to the procedure/module/whatever is involved. One "reported" bug could likely make many dozens or more other bugs readily apparent in your code.
It also teaches your organization how to avoid that bug in the future. How many bugs were in the wild, being used by blackhats for YEARS through multiple iterations of a software package before being caught?
Also, you get to find the mistake in the code and, if you're managing your code correctly, you will know who made the mistake. So you can coach if it was something that should have been caught.
And lastly, it solidifies your place in the market as a leader. People study your code intently, use it more, get more involved. The more people involved, the bigger your talent pool, the more industry respect you have, and as a result the more people will look to you as a company that cares about the stability and long term viability of your product.
I think all of that is true but doesn't negate the argument. Those are all great reasons to incentivize people to find bugs in your product. But if the state of the product is such that in practice it will always be possible to find another vulnerability for $50,000 worth of effort, and the vulnerability is worth $100,000 on the black market, someone will still find another vulnerability and exploit it.
First, bugs in a given program are not infinite in number. By definition. Because the code itself is finite. Finite code cannot have infinite bugs.
I agree... I did wrote, "Obviously the amount of vulnerabilities is not really infinite — you can only do finitely many things to a product in a finite amount of time, after all — but suppose it's so close to infinite as to make no difference, because the manufacturer would never be able to fix all the vulnerabilities that could be found for that amount of effort."
Also, due to the nature of code and how it is created, patching one bug usually also takes care of many others. If you have a buffer overflow problem in your input routine, you need only patch it once, in the routine. Not everywhere that routine is being called.
Right, I also said, "I'm hand-waving over some details here, such as the disputes over whether two different bugs are really considered "distinct," or the fact that once you've found one vulnerability, the cost of finding other closely related vulnerabilities in the same area of the product, often goes way down. But I don't think these complications negate the argument."
In fact I agree with everything you said, it just sounds like you're reaching the same conclusion that I did. Once you're done with in-house bug finding, offer a prize close to the black market value of an exploit in the software. If there are finitely many bugs in that range -- as you said, "You will usually only get a few to deal with before it gets quiet" -- then the prize will sweep them up.
Perhaps I should have emphasized: You don't have to start your bug-fixing by offering a prize, you can find as many of them as possible in-house, and from outsiders who report the easy bugs for free. You could even save money by starting with a lower prize, and then ramping it up slowly. (However, this runs the risk that someone might find a valuable bug early on, but keep it secret waiting for the prize money to go up. If they do this, they run the risk that someone else will find the same bug and claim the prize money and then the original discoverer gets nothing. But somebody still might try this. So that's a downside of slowly increasing the prize money.) As long as you end by offering a prize proportional to the black-market value of the vulnerability.
My point is that if there are (effectively) infinitely many bugs below the black-market value threshold, then the software isn't any less secure because you didn't fix a bug -- because you haven't changed the amount of effort it would take for the attacker to find their next vulnerability.
There aren't infinitely many criminals; crime rates are lower than they would be if we didn't arrest or prosecute criminals, because the population of criminals is finite and in fact small enough that our policing and sentencing policies can make a dent in it. (If there really were infinitely many criminals, then indeed it would be pointless to arrest or prosecute them, but there aren't.)
Is there a statement in this or some other article that you think is incorrect?
The analysis only applies to similar classes of vulnerabilities. If you find a remote root exploit in Apache with $5,000 worth of effort, but it turns out there are an effectively infinite number of remote root exploits that can also be found with $5,000 worth of effort, then in fact it is pointless to fix it since that is well below the black-market value of such an exploit, and new ones will never stop being found. But it's irrelevant if there are other far less serious bugs.
Paying people to find bugs and report them responsibly does give those people an incentive to not do something worse with them.
Right, I forgot to mention something: To prevent double-use like this, a company should say that you don't get paid until they've fixed the bug and issued a patch for it in their software, all without the exploit ever being spotted in the wild. (If someone else finds your vulnerability and exploits it in the wild, that's just bad luck. So to incentivize researchers, Microsoft might have to increase the prize money proportionally, to make up for the fact that sometimes people won't get paid because their exploits were found by someone else.) This incentivizes people to report bugs and not release them to the black market as well.
Yeah, I think $1,000 is way too low, I just used it as a sample number.
I think all that matters is that the dollar number matches the black-market value. Then it doesn't matter whether most people would find the effective hourly rate "insulting"; all that matters is that anybody who does find an exploit will turn it in to the company rather than selling it on the black market or exploiting it themselves.
Is there a statement in the article that you think is incorrect?
I have no relationship with those companies.
Interesting idea -- what kind of questions did you have in mind for a survey like that?
Part of my point was that people don't realize how inefficient the marketplace for ideas (and intellectual property generally) actually is, so I'm not sure what a survey should ask if I'm writing about a problem people aren't even aware of.
Right, it's spelled "narc'ed".
That's the conclusion. The article is the argument to support the conclusion.
There is a summary at the top: "If you read no further, use either the BestParking or ParkMe app to search all nearby parking garages for the cheapest spot, based on the time you're arriving and leaving. I'm interested in the question of why so few people know about these apps, how is it that they've been partially crowded out by other 'parking apps' that are much less useful, and why our marketplace for ideas and intellectual properly is still so inefficient."
That's two sentences, not a single sentence. Sorry.
The second sentence is "I'm interested in the question of why so few people know about these apps, how is it that they've been partially crowded out by other 'parking apps' that are much less useful, and why our marketplace for ideas and intellectual properly is still so inefficient." That's the conclusion; the example with the parking apps is the supporting argument. (I never called the online survey takers my "friends"; I said that I did two surveys, an informal poll of my friends and then a survey on Mechanical Turk.)
Agreed, the app should tell you if a garage is full. I don't know how easy it would be for an app developer to incorporate that though.
How often are garages full, anyway? I hardly ever see them full in Seattle, and I suspect the reason is that if a garage frequently fills up to capacity at any recurring time or under any foreseeable circumstance, the garage owner will realize that they can raise the price during that time or under that circumstance, and the garage will go back to not usually being full.
I'm not saying it's wasteful from the company's point of view; they spend money on marketing because it works.
I'm saying it's wasteful from an overall societal point of view, because if two companies spend money just trying to jostle each other out of the top spot on Google, the net gain will be zero. If they spent the same effort improving their products, and then the overall product quality determined their ranking in an information source like Google, the benefits would accrue to consumers.
Burning Man... narked... I see what you did there.
Bennett, I like all of your stuff and this is well-written but...
Troll! Get him, boys!
These apps are just going to increase mass neurosis. We don't need our heads filled with this crap. We need to spend more time thinking about important issues, not the trivia.
I think the more important issue is the general inefficiency in the marketplace for apps (as well as ideas and intellectual property in general). That was my main point. I wouldn't have written the article just to tell people about the parking apps, although I hope some people find that useful.
Let me address your objections separately: (1) that you think making it easy to get to Burning Man would lead people to come dangerously unprepared; and (2) that letting people get there with to little effort would ruin the culture.
Regarding (1), I did say, "These points should be taken in conjunction with a more comprehensive guide to preparing and packing; I'm not writing a full guide to getting ready for Burning Man. These just happen to be the points where I wasted the most time going down the wrong path during preparation, taking advice too literally from the BurningMan.com website and/or grizzled veterans who thought that you honor the event's heritage by doing things the hard way, before realizing there was a much easier option." I think a reasonable person could have interpreted that to mean they should read elsewhere for safety tips.
But let's say it's not inconceivable that by giving people an easy way, I encouraged some people to come who were less prepared. On the other hand, if you steer people towards the hard way of doing things (driving there from Louisiana, bringing a bike on the back of your car), that has safety consequences too. Driving that distance, you might have an accident, your car might break down in the heat, etc. Your own bike might be in less good shape than you think, and might cause an accident at BM or fall apart leaving you to make a long and strenuous walk back to camp.
A lot of those incidents could be avoided by people using the shortcuts I recommended. Those incidents, including safety hazards, are a cost of doing things the hard way, and I think it's a fallacy not to count them because either (a) they happen outside the gates of BRC or (b) people see a bike break or cause an accident and it never even occurs to them to think that it could have been avoided by steering that person towards a rental bike.
As for (2) the culture, I don't know of any camps that let you just "pay and show up". They're usually running a theme and require you to contribute a certain number of hours towards participating in the theme, immersing you in the aspect of culture that they are contributing to Burning Man.
Perhaps Burning Man could pre-emptively disallow "motel" camps that allow spots to the general public where you just "pay and show up". Presumably that would alleviate some of your concerns about pure tourists. But everybody has to start as a first-timer, and if a camp requires first-timers to spend time contributing to the camp project -- well, what else would you have them do?
And no, I never once thought either of these articles would ingratiate myself in the existing Burning Man community. On the contrary, as I said one of the subtexts was a critique of communities that won't give straightforward, helpful information to outsiders because they intentionally want to make things difficult for them. It's not just directions on how to get to Burning Man. Most directions, of all kinds, in all categories, suck, in the sense that you can tell the author did not, even once, show them to an outsider and say, "Read through these directions, and if there's any place where you get stuck or where there's something missing, tell me and I'll fix it." This shows a certain contempt for people who are outside the privileged community of insiders.
Most people have not been saying that anything in the original article was actually wrong; mostly I've been getting complaints that the advice makes it too easy for "tourists" to get there. Is there anything in it that you think is incorrect? (Re-reading it now, I probably should have emphasized to try and camp with friends before creating a "Burner Resume" and trying to get matched with a camp, but I figured that would be obvious to most people -- first try and find friends who are going, if you can. But even then, what's wrong with the "Burner Resume" approach? You said "That's not how you do it." Why not? You create a resume, you get matched with a camp, you pay them dues, you save some hassle and they come out ahead -- what's the problem? Unless you're still objecting to the fact that I'm making it "too easy".)
By contrast, the Survival Guide is wrong insofar as it tells you that it's highly recommended to bring your own bike, instead of mentioning the bike rental option, which is much more convenient for people who are flying and taking the Burner Express.
For heaven's sake, I just realized that last year's Survival Guide, in the section "Getting To And From Black Rock City", doesn't even mention Burner Express. I know you're not thrilled about the Sparkle Pony Express, but it's run by the official Burning Man corp. No, I would not call the Survival Guide a completely up-to-date source of the most useful information.
I'm aware of the fact that my original article sounds written someone who has only been to Burning Man once. But it still contains information that is missing from the Survival Guide and that none of the veterans told me when I asked them, but that I think is useful. In a way, that's one of the intended subtexts of the article: that a lot of BM veterans are so unhelpful to outsiders, that here I am having only been one time, and I'm still giving people more useful information than they would get from talking to a lot of the old-timers.
If you think I'm wrong, then again: Do you know of any written preparation guide for first-timers that is accurate and reasonably complete? (At minimum it should mention the Burner Express and the on-playa bike rental option.)