The title seems off. They haven't been caught yet. Burning man officials simply said they will find and cancel the tickets. That seems like something they might say regardless of whether they actually could do so.
Can anyone explain to me how they could go about determining who skipped the line and who didn't? I'm curious.
My understanding is that any users who entered the queue between 11:55ish (when the waiting room appeared) and 12:00 PST (when purchasing officially started) will have their tickets revoked.
I believe I may accidentally be one of these "hackers."
For those of you who don't know how the line worked, TicketFly sent registered users a link to a page that would allow them to purchase tickets at 12:00pm PST. Like most people, I clicked the link just before noon and ended up in a waiting room with a countdown clock and a note explaining that a continue button would appear at exactly 12:00.
My coworkers and I were curious if the button was simply hidden from view using JavaScript, so we did what any hackers (in the Hacker News sense) would do – we viewed the page's source. There it was! In the middle of the page sat a small javascript function with a link to reveal the button. Curious again, we clicked it. I believe the waiting room page just refreshed at that point, and we though nothing of it. A few minutes later, the queue began, and after sitting in it for about 40 seconds, I was shown the purchasing screen. I assumed I got lucky and left happy.
When I read this blog post on Saturday evening, I realized what had happened and freaked out a bit. It appears that clicking that link placed us at the top of the queue, even though we couldn't actually start the purchasing process until noon. Because of this, I am probably going to lose my tickets. Yet the fact that we could cut in line never even occurred to us, because we assumed that any queuing logic would have happened on the server side to prevent exactly this kind of exploit.
I feel bad for the users that I apparently cut in front of. I feel equally crappy, though, because I'm certain that other "hackers" are in similar situations to me. From what I've read in subsequent reports, using NoScript or otherwise browsing with Javascript disabled would have revealed the button before noon. That means that those people, too, will be labeled as hackers and have their tickets revoked. I'm relatively certain that even having a system clock running a few minutes early would mark you as a line cutter.
Not sure what to do next. I suppose all I can do is wait. This sucks.
I don't mean to be rude, but curiosity would've been viewing the source. Dropping into the queue early is when it got shady. Apologies if you lose your tickets, but it seems the fair way to handle the situation.
It doesn't matter if their technical solution wasn't perfect. It was good enough, and those who bypassed it (whatever their motives) showed up in the logs. Seems like it worked just fine.
That's the problem with the HN bubble. We seem to think everyone should come up with the perfect solution, when good enough carries the day.
Taking myself out of the equation then, since I understand that my actions may be construed as a gray area. If it turns out to be true that users with incorrectly set system clocks and users with javascript disabled accidentally cut the line, are they hackers? Should they have their tickets revoked?
As someone who has been in your shoes, I'm saying you're very much not a "hacker". You found a front-end weakness, exploited it, but the repercussions (if any) should be minor (ie tickets being kicked into the next sale for those who jumped the line).
In the grand scheme of things, this is as minor of an issue as it comes.
It sounds like, from your description, that if your system clock was running fast that would have also exposed the purchase button early. Can you tell if that's the case by looking at the source? If so, sounds like you have plausible deniability.
By whose definition? So if a site has elements on a page they do not want to be immediately seen their only choice is to not distribute the content? So if your circumventing a script that is not the same as circumventing a program?
I look at this way, if it does not occur to the common user to do so then it is "hacking". Not in any nefarious/sinister sense but the term still should apply.
If it is true that people visiting with Noscript or javascript disabled would see the button immediately then it is a design flaw of the ticketing system, not hacking.
At least they should've used javascript to generate the link and show it as opposed to hiding it on page load.
> if it does not occur to the common user to do so then it is "hacking".
This is the path to madness (and it's the one the "justice" system is on). Adblock? Hacking. Network connection blipped? Hacking. Using a new browser that better protects your privacy? Hacking. Changing number in URL? Hacking. Using a VPN? Hacking. Leaving page open for months in a forgotten tab? Hacking. Running any program that isn't a web browser? Hacking.
If our society is to have a digital future, the only sane definition is congruent to ownership and control - your computer functions wholly as your agent, and their server functions as theirs. Servers must be properly configured to enforce the desired business rules, and not doing so means different business rules are in effect.
I'm going with "plausible deniability." I have done this by accident by using a site with Javascript turned off (heck, I have coded something like this.) That's what happens when your code relies on client-side behavior that's not guaranteed.
It's certainly not in the spirit of the competition to get tickets. Just because the "inside knowledge" necessary to exploit the game is exceptionally simple doesn't make it OK to use it to your advantage, at least if you believe in fairness and equality.
The spirit of competition was wrecked by the choice to use client side time instead of server side time.
Would you run a race where every runner gets to choose when to begin?
Because that's what this is: A race without a central time authority. A race where each racer begins when his personal clock strikes "go".
Spirit of competition requires a fair playing field as a foundation, so there was no spirit of competition possible.
(NoScript also isn't against the 'spirit of competition'. If you want to ban a faster less-friction-causing swim suit, you have to ban it. You can't retroactively define the rules of competing!)
(Edit: Also, inventing rules of competition that aren't official rules to limit yourself to what you may consider 'honor' is called scrub logic. Play the game-- not your game, but rather the game as it exists with rules that are defined. If the rules aren't good enough, it's not the players fault).
Reminds me of a few free file hosts (probably now long dead) that would do the countdown thing client-side, with the direct link to download the file right there in the source code.
That sucks. In my eyes that's more on Ticketfly than on you. They have an event with ~400 dollar tickets that far more people want to pay for and attend than tickets are available. They should have made sure there system wasn't exploitable in this way.
Of course hindsight is always 20/20. It just doesn't seem fair that for clicking a link they served to your computer a few minutes early you'd get totally #$&$ed out of a ticket.
It doesn't seem fair you got to click the link a little early by peeking at the source but that shouldn't have been doable in the first place and they literally served you the key for access.
And that's why you never put that kind of logic on the front-end. Or if you do, always make sure there's a back-end double-check. In this case, from what I gather, an unique key that could only be known if people got it via an email would've been adequate.
> And that's why you never put that kind of logic on the front-end.
I wonder what kinds of goodies all these front end frameworks will lead to, when they eventually fall into the hands of people who don't understand that the final arbiter of some things must be on the back end.
That sounds like poor engineering in general - why would you trust the client on time sensitive issues? I'm predominantly a frontend engineer, but I make sure to understand the role of the technology I use and the responsibilities that need to be addressed by other sectors.
I've never been to this, and I'm pretty sure I wouldn't want to go. (When I go to the desert, it's not to be around other people.) However, this whole authority-obedience-fashion-and-privilege episode seems somewhat counter to my previous media-driven impressions of the event.
If you want to do something fun in the wilderness with your friends, you don't need anyone's permission for that.
Except in this case the Bureau of Land Management's (BLM) permission. I spent a lot of time in Las Vegas and for the most part you just drove out into BLM land and it was fine. But if you have a group greater than a certain size it requires permits. The tickets process is a way for them to not exceed their permit limit of 50,000 people. Doing so would get them banned from getting permitted in the future.
That said, I'm rather surprised at this point that some tech billionaire hasn't bought a couple of thousand of acres of desert[1] and allowed it to be run there. But at some point the 'exclusivity' becomes its own value.
Many ticket-limited events have figured out how to run a massive timed purchasing event like this. TicketFly could have checked out any one of them to learn how to properly execute this kind of event, and prevent "line-skipping". (ShmooCon and Playa Del Fuego are two such events i'm familiar with)
The system is very simple: you open up the ticket purchase page a few minutes before registration opens. The page reloads at randomish 30-second intervals. Once registration opens, the backend sets a queue number linked to a unique ID, and sets a cookie in your browser with that ID. You wait for the page to finally reload and say "it's your turn to purchase tickets!" And so, through a delayed system of individual registrations, everyone gets their ticket if they showed up at the appropriate time.
The 'queue' is a server-side aspect of this system, and it all happens on servers that have their clocks synchronized. Before accepting anyone into the queue, the server software needs to check if it's 12:00 yet (or whatever time registration opens).
Their software did not check the time before populating the queue. Bottom line: this was a bug in TicketFly's software, not "hacking".
The design is scalable to any ticket amount, given enough time and servers. You accept connections and assign queue numbers and then delay purchasing. You add randomization of various requests and entry in the queue itself to prevent gaming or latency-derived unfairness.
I've worked on websites that return hundreds of thousands of dynamic content pages per second, and you don't even need to do that here: all you need is a landing page that sets cookies, and then you can take all day to actually allow people to purchase with the reservation number they've got.
The bug has nothing to do with any of that, though...
That's entirely irrelevant unless you're arguing that 40k (and/or N number of attempted buyers) are too many items to manage in a queue on the server side. Is that what you're saying?
Doing the queue/first-come-first-serve thing only makes sense if you expect the number of people arriving at exactly the starting moment to be less than your supply of tickets. Otherwise what you have is a ticket lottery, except that the "randomization" is being done by ping times rather than anything explicit. If they can't expand the ticket supply by enough to meet demand, then they should probably make an explicit ticket lottery.
Doing a lottery also has the advantage that you can make some extra rules to make it more fair. For instance you can prefer people that didn't get tickets the year before.
Why do people need tickets to go out in the desert and have a big party?
Perhaps my thinking is naive here, but tickets seem to run counter to one of the main principles of Burning Man which is "Radical Self Reliance". If I'm paying you for a ticket then I must be relying on someone for security.
The tickets pay for several things including the permits to hold the event on federal land, the setup and cleanup of basic infrastructure, and the maintenance of basic facilities such as porta-potties.
47 comments
[ 5.4 ms ] story [ 33.5 ms ] threadUm, Larry and Sergey have been going to Burning Man since at least 1998:
http://www.theatlantic.com/technology/archive/2013/09/the-fi...
Can anyone explain to me how they could go about determining who skipped the line and who didn't? I'm curious.
For those of you who don't know how the line worked, TicketFly sent registered users a link to a page that would allow them to purchase tickets at 12:00pm PST. Like most people, I clicked the link just before noon and ended up in a waiting room with a countdown clock and a note explaining that a continue button would appear at exactly 12:00.
My coworkers and I were curious if the button was simply hidden from view using JavaScript, so we did what any hackers (in the Hacker News sense) would do – we viewed the page's source. There it was! In the middle of the page sat a small javascript function with a link to reveal the button. Curious again, we clicked it. I believe the waiting room page just refreshed at that point, and we though nothing of it. A few minutes later, the queue began, and after sitting in it for about 40 seconds, I was shown the purchasing screen. I assumed I got lucky and left happy.
When I read this blog post on Saturday evening, I realized what had happened and freaked out a bit. It appears that clicking that link placed us at the top of the queue, even though we couldn't actually start the purchasing process until noon. Because of this, I am probably going to lose my tickets. Yet the fact that we could cut in line never even occurred to us, because we assumed that any queuing logic would have happened on the server side to prevent exactly this kind of exploit.
I feel bad for the users that I apparently cut in front of. I feel equally crappy, though, because I'm certain that other "hackers" are in similar situations to me. From what I've read in subsequent reports, using NoScript or otherwise browsing with Javascript disabled would have revealed the button before noon. That means that those people, too, will be labeled as hackers and have their tickets revoked. I'm relatively certain that even having a system clock running a few minutes early would mark you as a line cutter.
Not sure what to do next. I suppose all I can do is wait. This sucks.
I don't mean to be rude, but curiosity would've been viewing the source. Dropping into the queue early is when it got shady. Apologies if you lose your tickets, but it seems the fair way to handle the situation.
My suggestion? Don't put your queue in my computer.
That's the problem with the HN bubble. We seem to think everyone should come up with the perfect solution, when good enough carries the day.
In the grand scheme of things, this is as minor of an issue as it comes.
Obviously not.
Viewing page source and navigating to a URL which is clearly visible is not subversive in any way.
I look at this way, if it does not occur to the common user to do so then it is "hacking". Not in any nefarious/sinister sense but the term still should apply.
https://www.reddit.com/r/BurningMan/comments/2wieta/did_you_...
EDIT: Typo
This is the path to madness (and it's the one the "justice" system is on). Adblock? Hacking. Network connection blipped? Hacking. Using a new browser that better protects your privacy? Hacking. Changing number in URL? Hacking. Using a VPN? Hacking. Leaving page open for months in a forgotten tab? Hacking. Running any program that isn't a web browser? Hacking.
If our society is to have a digital future, the only sane definition is congruent to ownership and control - your computer functions wholly as your agent, and their server functions as theirs. Servers must be properly configured to enforce the desired business rules, and not doing so means different business rules are in effect.
Would you run a race where every runner gets to choose when to begin?
Because that's what this is: A race without a central time authority. A race where each racer begins when his personal clock strikes "go".
Spirit of competition requires a fair playing field as a foundation, so there was no spirit of competition possible.
(NoScript also isn't against the 'spirit of competition'. If you want to ban a faster less-friction-causing swim suit, you have to ban it. You can't retroactively define the rules of competing!)
(Edit: Also, inventing rules of competition that aren't official rules to limit yourself to what you may consider 'honor' is called scrub logic. Play the game-- not your game, but rather the game as it exists with rules that are defined. If the rules aren't good enough, it's not the players fault).
Of course hindsight is always 20/20. It just doesn't seem fair that for clicking a link they served to your computer a few minutes early you'd get totally #$&$ed out of a ticket.
It doesn't seem fair you got to click the link a little early by peeking at the source but that shouldn't have been doable in the first place and they literally served you the key for access.
I wonder what kinds of goodies all these front end frameworks will lead to, when they eventually fall into the hands of people who don't understand that the final arbiter of some things must be on the back end.
Because someone only has a superficial understanding of how things work.
If you want to do something fun in the wilderness with your friends, you don't need anyone's permission for that.
That said, I'm rather surprised at this point that some tech billionaire hasn't bought a couple of thousand of acres of desert[1] and allowed it to be run there. But at some point the 'exclusivity' becomes its own value.
[1] Land ownership debates not withstanding.
The system is very simple: you open up the ticket purchase page a few minutes before registration opens. The page reloads at randomish 30-second intervals. Once registration opens, the backend sets a queue number linked to a unique ID, and sets a cookie in your browser with that ID. You wait for the page to finally reload and say "it's your turn to purchase tickets!" And so, through a delayed system of individual registrations, everyone gets their ticket if they showed up at the appropriate time.
The 'queue' is a server-side aspect of this system, and it all happens on servers that have their clocks synchronized. Before accepting anyone into the queue, the server software needs to check if it's 12:00 yet (or whatever time registration opens).
Their software did not check the time before populating the queue. Bottom line: this was a bug in TicketFly's software, not "hacking".
That's an order of magnitude difference.
I've worked on websites that return hundreds of thousands of dynamic content pages per second, and you don't even need to do that here: all you need is a landing page that sets cookies, and then you can take all day to actually allow people to purchase with the reservation number they've got.
The bug has nothing to do with any of that, though...
Perhaps my thinking is naive here, but tickets seem to run counter to one of the main principles of Burning Man which is "Radical Self Reliance". If I'm paying you for a ticket then I must be relying on someone for security.
They publish a great breakdown of where the money goes here: http://burningman.org/event/preparation/ticket-money/