Dev:Tweak DRM

Building tweak DRM means building technical measures to control access to using a tweak you made, especially to prevent access by people who were supposed to pay for it but didn't, aka pirates. (DRM stands for digital rights management.)

Philosophical advice
Many developers choose to skip working on DRM for their paid tweaks and instead spend that time on making a great piece of software with lots of marketing and good support. Almost all DRM systems get cracked; many people who crack software have more free time than you do.

If you choose to implement DRM, you need to build it in a way that preserves access for legitimate users even if your DRM system fails. If your server goes down (and it'll inevitably go down), or if other mistakes happen, that must not prevent access to your product for people who have purchased it. saurik is willing to block purchases of Cydia Store products with faulty DRM, and the default repositories (especially BigBoss) also don't consider faulty DRM acceptable.

Some advice from saurik:

"DRM...increases the risk of your product receiving complaints, complaints that will translate into your vendor account no longer being trusted and your products being blocked from sale. This instead must be viewed as a tradeoff that you must consider."

"I do not consider hard DRM checks that happen during package scripts acceptable. For various reasons (related to how other packages that modify things related to network access are implemented) it cannot be assumed to be the case that Cydia still has working Internet access during the package installation phase (all packages are downloaded before this phase begins, which then happens as a semi-atomic unit)."

"However, the entire idea of having a DRM system that doesn't let the user use the product they just purchased unless your server is working at that very first instant is fundamentally flawed: even simple networking glitches or inevitable hardware failures lead to situations where users can't enable their purchases. You thereby really need some kind of "leniency" or "grace period" in your implementation to be acceptable."

"One common way of getting most of the way there is simply to implement a trial period for the product: the trial period tends to act as a buffer, decreasing the number of people who experience the failure (as most people who ever purchase at all actually purchase quite quickly and do not wait for the product to entirely expire). A more epic implementation involves a model where the system gives the user a few hours of grace."

Practical advice
It's reasonable to make pirated versions display a friendly message (as a pop-up, as a banner in settings, or similar) that explains that (1) it's a pirated tweak, and (2) please uninstall this pirated version and purchase the legitimate version from the authorized repository, with a link to the proper package page. If this message is polite and not very annoying, tweak crackers might not bother to patch it out.

It's fair to make pirated versions of your tweak not work, but keep in mind that if you do this without explaining why, this may confuse people into thinking the tweak doesn't work at all, even for paid users. (Some people do use piracy to "try before they buy".) Also, tweak crackers like to find ways to bypass this so that the pirated tweak will work.

Keep in mind that some people pirate without realizing that they're using pirated versions - for example, their friend suggested that they add a shady repository, and they ignored the pirate warning on the repository. This is part of why it's helpful to include a clear message explaining that it's pirated.

Not recommended
DRM shouldn't act like malware. Some of the things your DRM shouldn't do:


 * Don't take action without permission from users, even if the person has pirated your package - for example, don't modify people's /etc/hosts files or send tweets without permission. This kind of negative surprise makes users angry and reduces their trust in you, which doesn't make them want to support you by purchasing your package.
 * Don't do annoying things to the device that frustrate people, such as making the screen black after they install a pirated package, even if that's solvable by going into safe mode and uninstalling the package. This makes users scared and irritated - they'll be angry at you instead of wanting to support your work by purchasing the package.
 * Don't cause unrelated problems that make people think there's something wrong with their jailbreak, such as making SpringBoard randomly crash once in a while - pirates are just going to think that they need to restore and go back to normal iOS, instead of realizing that installing your specific package caused their problem. You want to encourage them to purchase your package, not make them think jailbroken devices are unreliable.
 * Don't cause harm to files or the operating system (such as damaging system files, intentionally causing bootloops, etc.) - this is bad and will get your package purchase-blocked by saurik and/or removed from default repositories.

Also, please don't make life difficult for other tweak developers who may need to coordinate their work with your work - for example, don't disable debuggers or other tools developers use.

Technical advice
You can add some advice here about writing good DRM!

Cydia Store Integration and crack prevention might be helpful articles.

You can also ask experienced developers for advice on this. One suggestion:

I've used a few different lightweight forms of DRM that don't interfere with User Experience at all, most of which have been unsuccessful (only delaying the inevitable). But there are a few schemes that can be successfully implemented (and so far moderately unbeaten) with appropriate use cases of the tweak. Message me on twitter (@apocolipse269) or IRC (apocolipse on ircsaurik, freenode, chronic-dev, etc) and I can offer some advise. -Apocolipse

Here's a thread on /r/jailbreak with some examples from developers.