This statement is on behalf of my KOS team, the rest of whom are @d1en, @jdeng, and @samrs.
First of all, people are calling this a “hack” or an “exploit”, which is more sensational than it needs to be. The trick is simply that you can take the deck ID number in the URL of an unpublished deck and increment or decrement it to find other unpublished decks created near the same time. The truth is that we are not innocent of this trick, so I want to share exactly what we did.
We 4 became aware of the trick last friday and learned that other teams were using it for playtesting purposes, and immediately agreed that that was unsporting, although a gray area whether outright cheating. Sam spent 20 minutes trying various deck ID URLs by hand and found 5 decklists. I then wrote a 20 line script to do that automatically and print the author names, and ran it long enough to find 18 deck IDs from players I recognized. I looked at the decklists long enough to confirm the script worked, but didn’t study them, and don’t remember any of the contents now. Jason read my script to see how easy the trick was, at which point we realized we should absolutely not use these results for playtesting. Dien in particular steered us to the right path here and it’s largely to his credit that we stopped short of studying the decklists. Basically, we decided that rather than complicitly entering the world of “well other teams are doing it so we should too”, we should instead level the playing field by trying to fix the vulnerability.
Jason and I then discussed what kind of change to NRDB would prevent decklist scraping. The simple answer is to “salt” the URLs; i.e., append a random string of digits to the deck ID that can’t just be guessed by incrementing a number. Sam began warning other deckbuilders who were likely affected to make their decklists private, and Jason told Alsciende about the trick, who implemented a temporary fix to at least hide the author names on unpublished decks. Jason then wrote a pull request to salt the URLs, which should be applied soon (the remaining issue is to decide whether it should apply to all decklists and break old links, or to future decklists only).
I watched the conversations on slack in the aftermath and some people seem to be under the impression that we scraped decklists as a proof-of-concept that was a necessary step in diagnosing and fixing the vulnerability. That is totally wrong – as I said in the first paragraph, it’s just basic addition at the heart of the trick, and a little bit of web security knowledge to decide how to fix it. There was no need to actually scrape decklists. I wrote our proof-of-concept script for no reason other than thoughtless curiosity. I want to stress that we did not study any decklists we scraped for playtesting purposes, but I still absolutely regret that we violated people’s expectation of privacy by running the script at all, and for that I apologize. I hope we can make things right by collaborating with Alsciende to make NRDB more secure in the future.