Live data from Hacker News

Ask HN: What is the sensible way to sell offline desktop applications?

news.ycombinator.com

1–10 of 20 posts

Ask HN: What is the sensible way to sell offline desktop applications?

#1
I have some side projects that I'd like to sell as commercial applications. These don't really provide any "ongoing service", so I'd feel bad with asking for a subscription fee, meaning ideally a small flat fee per license should suffice.

How does one achieve this in a sane, reasonable way in 2022? I don't want to ship an annoying "activator" program like something from Autodesk or Adobe, which goes against the idea of my simpler applications.

On the other side of the spectrum I feel like I could just provide a link to a zip on an S3 on the payment confirmation email, but that is easily shareable and looks unprofessional.

Is there something that can be done with encryption/activation keys that would not require the program to phone home to validate itself every time its launched?

How do you people earn money from your desktop applications?

Re: Ask HN: What is the sensible way to sell offline desktop applications?

#2
I would go with something simple.

Quote from Stack Overflow:

“Simple answer - No matter what scheme you use it can be cracked.

Don’t punish honest customers with a system meant to prevent hackers, as hackers will crack it regardless.

A simple hashed code tied to their email or similar is probably good enough.”

https://stackoverflow.com/a/599841

Re: Ask HN: What is the sensible way to sell offline desktop applications?

#3
Something you see quite often are named licenses that then show up somewhere in the UI. "XYZ App licensed to ". Doesn't stop people copying, but at least looks bad for them. Doesn't prevent someone cracking your software and just ripping out that function of course. Companies used to put lots of effort into making reverse-engineering that hard and there's probably a few companies still selling tooling around that, but realistically it's probably wasting your time to overcomplicate that. Basic license file just has some serial, the registered name and then a digital signature your software checks, customer can download license file on purchase. I've seen personalized executables/installers too, but that's a pain with e.g. code signing.

Anything else requires phoning home or exotic solutions like hardware tokens.

Re: Ask HN: What is the sensible way to sell offline desktop applications?

#4
With something like MobaXterm, they allow you to download a limited version of the product for free, and a full version of the program hidden behind an online account.

When you pay for the software, it generates an account you can use to log into their website and allows access to the paid version of the product.

Not sure if it phones home, but having a login/password combo restricting access to the paid version of your product would likely be "good enough" without having to use "check if I'm registered" online logic.

Of course, if they decide to share the program then you don't have any recourse but that might not be a huge problem, depending on how honest your customers are.

Re: Ask HN: What is the sensible way to sell offline desktop applications?

#5
I work in theatre tech in Baltimore, and Figure53’s QLab software has a good model: You sign up for an account, you can purchase a license, you can download the software onto machines, you can open files for free but need a license to save edits, licenses can be activated online or offline-with-a-code, devices basically never need to go online (unless their license has an expiration date), and it all basically just works.

There are probably some people who have done the offline activation thing and then never brought the device in question online again (or blackhole Figure53’s DNS from that device), but I think Figure53 has decided to just eat that cost, and I doubt it costs them much.

Re: Ask HN: What is the sensible way to sell offline desktop applications?

#6
I think you can solve this with public key cryptography, your public key ships with the program.

Then you sign (HMAC) something unique to the user (such as email address) along with an expiry date.

That signed message becomes the 'key' they enter.

The software validates the message at the same time as parsing out their email address and the key expiry date from the message.

This doesn't require any phoning home.

This doesn't stop multiple use unless you start requiring an initial phone home where hardware IDs are provided and incorporated into the hashed+signed message. That only requires phoning home once and doesn't need phoning home every start.

Re: Ask HN: What is the sensible way to sell offline desktop applications?

#8
One of the simple solutions I like most is to distribute a license file after purchase. The license can be a JWT or an X509 cert or something else with a signature you can verify offline in the app.

It will not prevent multiple use without phoning home but I don't think it's that much of an issue. Pirates are not going to pay for your software anyway.

Re: Ask HN: What is the sensible way to sell offline desktop applications?

#10
post #6

I think you can solve this with public key cryptography, your public key ships with the program. Then you sign (HMAC) something unique to the user (such as email address) along with an expiry date. That signed message becomes the 'key' they enter. The software validates the message at the same time as parsing out their email address and the key expiry date from the message. This doesn't require any phoning home. This…

You shouldn't use an HMAC here, since that's symmetric and the key sits inside the app. You should use public key crypto as you suggested - sign the serialised per-user information (technically you generally sign the hash of it, but don't roll your own crypto, use a proven library), and give the user that signature (along with the message that's signed) as a "license file".

Patching this requires modifying every future version of the software, since it isn't feasible for most people to generate a false licence. You could include a maximum version field in the licence, or an expiry date (which relies on the user's local clock, but could also check against the time of a given build as a sanity check).

Post reply on HN