Strategie di prova / licenze [chiuso]

Question

Ho scritto un'utilità per i fotografi che ho intenzione di vendere online abbastanza a buon mercato ($ 10). Vorrei consentire all'utente di provare il software per circa una settimana prima di richiedere una licenza. Dato che si tratta di un progetto personale e che il software non è molto costoso, non credo che l'acquisto di servizi di fornitori di licenze professionali varrebbe la pena e sto realizzando il mio.

Attualmente l'applicazione verifica la presenza di una chiave di registro che contiene una stringa crittografata che specifica quando scade il periodo di prova o che dispone di una licenza valida. Se la chiave non è presente, viene creata una chiave del periodo di prova.

Quindi tutto ciò che dovresti fare per ottenere un'altra settimana gratuitamente è eliminare la chiave di registro. Non credo che molti utenti lo farebbero, specialmente quando l'app costa solo $ 10, ma io Sono curioso di sapere se esiste un modo migliore per farlo che non sia oneroso per l'utente legittimo. Scrivo app Web normalmente e non ho mai affrontato queste cose prima.

L'app è in .NET 2.0, se è importante.

Answer 1

EDIT: puoi rendere il tuo attuale schema di licenze molto più difficile da decifrare memorizzando le informazioni del registro nell'autorità di sicurezza locale (LSA). La maggior parte degli utenti non sarà in grado di rimuovere le informazioni chiave da lì. Una ricerca di LSA su MSDN dovrebbe fornirti le informazioni di cui hai bisogno.

Le opinioni sugli schemi di licenza variano da individuo a individuo, più tra gli sviluppatori che specifici gruppi di utenti (come i fotografi). Dovresti fare un respiro profondo e provare a vedere cosa accetterebbe l'utente target, dato il bisogno aziendale che la tua applicazione risolverà.

Questa è la mia opinione personale sull'argomento. Ci saranno individui vocali che non sono d'accordo.

La risposta a ciò dipende in gran parte da come ci si aspetta che venga utilizzata l'applicazione. Se si prevede che l'applicazione venga utilizzata più volte al giorno, si trarrà il massimo beneficio da un periodo di prova molto lungo (diversi mesi), per creare una situazione di blocco. Affinché ciò funzioni, dovrai disporre di un periodo di tolleranza in cui il software avvisa l'utente che il pagamento sarà presto necessario. Prima del periodo di tolleranza avrai maggior successo se il software non tace sul periodo di prova.

Sia che tu scelga di credere in questa affermazione piuttosto audace, dipende ovviamente da te. Ma se lo fai, dovresti capire che meno spesso verrà utilizzata l'applicazione, più breve dovrebbe essere il periodo di prova. È anche molto importante che il pagamento sia molto rapido e semplice per l'utente (il minor numero possibile di dati e il minor numero di clic possibile).

Se non si è sicuri dell'utilizzo dell'applicazione, è necessario scegliere un periodo di prova molto breve. Nella mia esperienza, otterrai risultati migliori se l'applicazione non parla del fatto che è in questo periodo di prova.

Sebbene efficace ai fini della licenza, " Chiama casa " le funzionalità sono considerate una minaccia alla privacy da molte persone. Personalmente non sono d'accordo con l'idea che ciò sia un male per un cliente che è disposto a pagare per il software che sta usando. Pertanto suggerisco di implementare uno schema di licenze in cui l'applicazione controlla regolarmente lo stato della licenza (di prova, a pagamento) e aiuta l'utente a pagare il software quando è il momento. Questo potrebbe essere eccessivo per una piccola applicazione di utilità, tuttavia.

Per applicazioni di utilità molto piccole o addirittura semplici, sostengo che il pagamento anticipato senza periodo di prova sia il più efficace.

Per quanto riguarda la sicurezza della soluzione, è necessario renderla proporzionale allo sforzo di sviluppo. Nella mia linea di lavoro, la sicurezza è molto critica perché ci sono partner e rivenditori coinvolti e perché l'investimento fatto nello sviluppo è molto elevato. Per una piccola applicazione di utilità, ha più senso valutare il prezzo giusto e fare affidamento sugli utenti onesti che pagheranno per il software che risponde alle loro esigenze aziendali.

Answer 2

Non ha molto senso fare complicati schemi di protezione. Fondamentalmente accadrà una delle due cose:

1. La tua app non è abbastanza popolare e nessuno la spacca.

2. La tua app diventa popolare, qualcuno la rompe e la rilascia, quindi chiunque con zero conoscenza può semplicemente scaricare quella crepa se vuole ingannarti.

Nel caso del n. 1, non vale la pena impegnarsi molto nello schema, perché potresti fare acquistare una o due persone extra alla tua app. Nel caso del n. 2, non vale la pena impegnarsi molto perché qualcuno lo spezzerà comunque e lo sforzo verrà sprecato.

Fondamentalmente il mio suggerimento è semplicemente fare qualcosa di semplice, come lo sei già, ed è altrettanto efficace. Le persone che non vogliono imbrogliare / rubare da te pagheranno, le persone che vogliono imbrogliare te lo faranno indipendentemente.

Answer 3

Se stai ospitando la tua homepage su un server che controlli, potresti avere la versione di prova scaricabile del tuo software compilare automaticamente su un nuovo binario ogni notte. Questa compilazione sostituirà un valore datetime codificato nel programma per quando scade il software. In questo modo, l'unico modo per "imbrogliare" è cambiare la data sul tuo computer e la maggior parte delle persone non lo farà a causa dei problemi che si creeranno.

Answer 4

Prova lo Starter Kit Shareware. È stato sviluppato da Microsoft e potrebbe avere alcune altre funzionalità desiderate.

http://msdn.microsoft.com/en-us/vs2005 /aa718342.aspx

Answer 5

Se stai pensando di continuare a sviluppare il tuo software, potresti prendere in considerazione il modello di riscatto:

http://en.wikipedia.org/wiki/Street_Performer_Protocol

In sostanza, sviluppi miglioramenti al software e poi chiedi una certa quantità di donazioni prima di rilasciarle (senza DRM).

Answer 6

Un modo per farlo che è facile per l'utente ma non per te è programmare la data di scadenza e creare nuove versioni del programma di installazione ogni tanto ... :)

Se fossi in te, però, non lo farei più avanzato di quello che stai già facendo. Come dici tu, costa solo $ 10 e se qualcuno vuole davvero rompere il tuo sistema, lo farà indipendentemente da quanto sia complicato.

Potresti realizzare una versione leggermente più avanzata del tuo schema richiedendo una connessione di rete e lasciando che un server generi la chiave di prova. Se fai qualcosa sulla falsariga del segno (hash (unique_computer_id + when_to_expire)) e consenti all'app di verificare con una chiave pubblica che il tuo server abbia firmato la data di scadenza, dovrebbe richiedere un " real " hack per bypassare.

In questo modo è possibile memorizzare il lato server dell'ID univoco e rifiutare di generare una data di scadenza più di una o due volte. Non sei sicuro di cosa utilizzare come ID univoco, ma dovrebbe esserci un modo per ottenere qualcosa di utile da Windows.

Answer 7

Sto affrontando lo stesso problema con un'applicazione che vendo anche a un prezzo molto basso.

Oltre a offuscare l'app, ho ideato un sistema che utilizza due chiavi nel registro, una delle quali viene utilizzata per determinare il tempo di installazione, l'altra la chiave di licenza effettiva. Le chiavi sono nominate in modo oscuro e una chiave mancante indica manomissione dell'installazione.

Ovviamente l'eliminazione di entrambe le chiavi e la reinstallazione dell'applicazione riavvieranno nuovamente il tempo di valutazione.

Ho pensato che non importa comunque, poiché qualcuno che vuole crackare l'app riuscirà a farlo, o troverà una crepa da qualcuno che è riuscito a farlo.

Quindi alla fine sto solo raggiungendo l'obiettivo di rendere TROPPO semplice non riuscire a decifrare l'applicazione, e questo è ciò che, suppongo, impedirà all'80-90% dei clienti di farlo. E dopotutto: poiché l'applicazione viene venduta a un prezzo molto basso, non c'è giustificazione per me investire più tempo in questo problema di quanto non abbia già fatto.

Answer 8

sii gentile con la licenza. spiega in anticipo che questa è la tua passione e un figlio del tuo lavoro. dare alle persone la possibilità di fare la cosa giusta. se qualcuno vuole piratarlo, accadrà alla fine. Ricordo ancora la mia disperazione nel vedere i miei libri su bittorrent, ma è qualcosa che devi affrontare. Non andare alla pirateria occasionale (quello che stai facendo ora suona alla grande) ma non paralizzare la cosa oltre. Credo ancora che ci siano abbastanza persone oneste là fuori per fare valere un tentativo di codifica a scopo di lucro.

Answer 9

Non effettuare la valutazione in base a "giorni dall'installazione", invece indica il numero di giorni utilizzati, il numero di volte in esecuzione o qualcosa di simile. Le persone tendono a scaricare shareware, eseguirlo una o due volte e quindi dimenticarlo per alcune settimane fino a quando non ne hanno più bisogno. A quel punto, la versione di prova potrebbe essere scaduta e quindi hanno avuto solo pochi tentativi di agganciarsi utilizzando l'app, anche se l'hanno installata da un po '. Il numero di attivazione / giorni invece consente loro di prendere l'abitudine di utilizzare la tua app per un'attività e rende anche una vendita più forte (ovvero hai usato questa app 30 volte ...).

Ancora meglio, limitare le funzionalità funziona meglio del timeout. Ad esempio, forse la tua app per la fotografia potrebbe limitare l'utente a immagini da 1 megapixel, ma lasciarlo usare per tutto il tempo che desidera.

Inoltre, valuta il prezzo della tua app a $ 20 (o $ 19,95). A meno che non sia già presente una configurazione di micropagamento (come iPhone store o XBoxLive o qualcosa del genere) le persone tendono ad avere un'avversione per l'acquisto di cose online al di sotto di un determinato prezzo (che è di circa $ 20 a seconda del tipo di app) e le persone assumono in modo subconscio se qualcosa è poco costoso, non deve essere molto buono. Puoi effettivamente aumentare il tasso di conversione con un prezzo più elevato (fino a un certo punto).

Answer 10

In questo tipo di circostanze, non penso davvero che importi ciò che fai. Se hai un qualche tipo di protezione, il 90% dei tuoi utenti verrà bloccato. L'altro 10%: se non vogliono pagare per il tuo software, troveranno praticamente un modo per aggirare la protezione, qualunque cosa tu faccia.

Se vuoi qualcosa di un po 'meno ovvio puoi inserire un file in System32 che suona come un file di sistema di cui l'applicazione verifica l'esistenza all'avvio. Questo può essere un po 'più difficile da rintracciare.