If the time it took to reverse enough of Spotify to find this trick was worth more than the N months of what Spotify was trying to protect (prior to the disclosure of the problem), then the trick was a net win for Spotify. That's the basis of DRM.<p>Want to make this a modern scheme?<p>* Make it much, much harder to reverse enough of Spotify to find tricks like this. Encrypt code with a "white-box" variant of an intentionally obfuscated algorithm. Compile numerous dead-code dead-end encrypted code paths into the binary.<p>* Make the scheme <i>renewable</i>, so that instead of simply making a binary decision about whether the program can run or not run, it derives a secret that all valid instances of the program need to operate. Now when someone breaks the scheme (as inevitably they will), release an update with different compiler tricks and a different secret.<p>* Stockpile a lot of these variants (it is easier for you to do this than for attackers to reverse those tricks, which returns the advantage to you). Make update transparent. Trickle out updates until attackers get bored and go away.<p>This is essentially the BD+ DRM scheme, which has kept Slysoft mostly on their heels (multi-week delays on new titles were typical, last I checked). And BD+ had a much harder problem to solve, since they had to coordinate the scheme amongst lots of consumer electronics vendors. You can do better.