[HN Gopher] Ask HN: What is the sensible way to sell offline des...
___________________________________________________________________
Ask HN: What is the sensible way to sell offline desktop
applications?
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?
Author : wallfacer77
Score : 19 points
Date : 2022-03-29 20:32 UTC (2 hours ago)
| beamatronic wrote:
| My standard for this kind of thing is Beyond Compare by Scooter
| Software. You purchase a licence key which arrives via email and
| you copy and paste it into the application, which activates it
| permanently.
| cpach wrote:
| 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
| zorr wrote:
| 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.
| detaro wrote:
| Something you see quite often are named licenses that then show
| up somewhere in the UI. "XYZ App licensed to <name>". 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.
| wmf wrote:
| App stores.
| smackeyacky wrote:
| 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.
| Uehreka wrote:
| 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.
| eterm wrote:
| 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.
| g_p wrote:
| 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).
| eterm wrote:
| Thanks for the correction, I didn't realise HMAC was only
| symmetric and thought it generally covered signing of hashed
| messages.
___________________________________________________________________
(page generated 2022-03-29 23:02 UTC)