Implementazione di una cronometro di 30 giorni

Domanda per gli sviluppatori di Mac indie là fuori:

Come posso implementare una prova a tempo di 30 giorni in modo non malvagio? Mettere un contatore nei prefs non è un’opzione, dal momento che pulire i prefetti una volta al mese non è un problema per un utente medio. Mettere il contatore in un file nascosto da qualche parte suona un po ‘schivo – come un utente che odio quando le app cospargono il mio disco rigido con file casuali. Qualche idea?

    Questo problema si presenta ripetutamente nella mailing list cocoa-dev e la risposta di consenso è sempre fare la cosa più semplice ansible. Gli hacker risolti romperebbero tutto tranne la soluzione più ingegnerizzata. Ed è improbabile che paghino per il software comunque. Scegli la soluzione 80/20: la soluzione facile che ottiene un effetto dell’80% con uno sforzo del 20%. In questo caso, mettere qualcosa in ~ / Library / Application Support / your.app.com /. Potresti nominare il file qualcosa di innocente se vuoi offuscare un po ‘le cose. Anche l’utilizzo delle impostazioni predefinite dell’utente è semplice.

    Qualunque cosa tu faccia, non utilizzare l’indirizzo MAC o un altro ID hardware. Gli utenti con una home directory di rete (ad esempio in un’impostazione di laboratorio condivisa) ti odieranno. Usare gli ID hardware è semplicemente malvagio.

    Se qualcuno è innamorato del tuo programma così tanto da essere disposto a infrangere i tuoi limiti di prova, lasciali fare. Il software gratuito non ti costa nulla e la loro buona volontà (e forse la raccomandazione agli altri) vale molto.

    Infine, scrivi software che le persone vogliono usare e valutarne il valore. Se il tuo prezzo è un buon valore e la gente vuole usarlo, la maggior parte delle persone pagherà per questo.

    Vorrei suggerire di implementare alcune delle cose che sono meno invadenti e potrebbe evitare un utente normale di disinstallare o acquistare in un mese.

    1. Utilizzare una serie speciale di numero di serie di prova che memorizza la data di scadenza in esso. È ansible utilizzare l’encrpy per memorizzare la data di scadenza all’interno del numero di serie.
    2. Ora crea un file di configurazione che memorizza i dati nel formato crittografato e contiene il numero di serie.

    Inoltre, implementa queste cose nel file di configurazione.

    1. Annotare la data / ora ogni volta che l’utente avvia l’applicazione.
    2. Si noti la durata dell’applicazione temporale aperta.

    Effettuando la registrazione del timestamp è ansible evitare questi aggiramenti:

    1. Se l’utente inverte la data del computer, sapresti che l’app era già stata eseguita quel giorno. Supponi che l’utente abbia eseguito l’app il 1 ° e il 3 ° giorno del mese. Ora dopo 30 giorni inverte la data e la imposta al 2 ° del mese. Ora dal file di configurazione sapresti che l’app è già in esecuzione su 1 e 3, quindi l’utente ha incasinato le date sul computer.
    2. Diciamo ogni volta che l’utente avvia la tua app impostando prima la data al 5 del mese. Registrando il tempo di esecuzione della tua applicazione, vedresti che se le ore totali in un giorno superano i 24, allora l’utente sta scherzando.

    Assicurati che la tua app non funzioni senza il file di configurazione. Quindi in sostanza si invia il numero di serie crittografato in un file o forse al momento dell’inserimento del numero di serie è ansible creare il file. Poiché il numero di serie ha già la data di scadenza, l’utente non può riutilizzare anche il numero di serie.

    Non suggerirei la via Internet perché la gente si incazza quando l’app cerca di connettersi al server ogni volta. Inoltre, si potrebbe avere il sospetto che si sta tentando di inviare alcuni dati personali degli utenti ai propri server.

    Una cosa che vorrei dire: non importa quanto sia forte la tecnica antipirateria che usi, qualcuno è destinato a romperlo. Non stai realizzando la tua app per quei ragazzi. Stai creando la tua app per le persone che vorrebbero il tuo software e lo acquisteranno felicemente. Quindi, limitare l’anti-pirateria senza perdere i veri clienti rendendo la tua applicazione troppo invadente durante il periodo di prova. Un pensiero dice anche che se il tuo software si sta rompendo significa che sta diventando popolare anche. Anche in questo caso le opinioni possono essere diverse e non vorrebbero divagare su questi temi.

    Considera questo. Quanti potenziali utenti del tuo software ci sono, solo prurito per usarlo solidamente per i prossimi 30 giorni?

    Sospetto che il caso più normale sia: gli utenti incontrano un nuovo pacchetto software che risolve un problema che hanno avuto su un sito come lifehacker.com. il software viene scaricato, riprodotto brevemente, quindi messo da parte. Forse il suo software di ripping mp3 e non hanno alcun cd da copiare in quel momento. O sono solo occupati quel giorno, ma torneranno a rivedere quel software ‘presto’.

    30 giorni di abbonamento. Probabilmente di più Solo Allora comprano un CD, incontrano una sorta di ‘problema’ e ricordano, ‘aha, c’è la versione di prova che ho scaricato! Dove l’ho riposto? ‘ Non importa. Senza mai essere utilizzato, il “processo” è scaduto.

    Non posso contare il numero di strumenti software che sono caduti in quel secchio per me. Il giorno in cui mi viene consigliato un software, il giorno in cui vedo una recensione positiva su lifehacker, non è MAI il giorno in cui ho effettivamente bisogno – o anche il tempo – di usare / analizzare il programma che ho scaricato e installato.

    Avere il software scaduto dopo 30 giorni di calendario è sbagliato, perché se qualcuno lo scarica, lo esegue una volta e poi decide di valutarlo un mese dopo? La prossima volta che la lanceranno, un mese dopo, dirà che è scaduta.

    Mi piacerebbe averlo limitato a 14 lanci, o qualcosa come 120 minuti di utilizzo.

    Per quanto riguarda l’implementazione, un file (nascosto o meno) nella cartella delle preferenze dell’utente, con un nome offuscato, sembra il modo migliore per andare. Il file non è posizionato casualmente sul disco rigido, ma l’utente non può facilmente capire quale file eliminare.

    Il modo meno pericoloso è chiedere all’utente di cancellare il programma dopo un mese o di pagarlo;)

    Lo abbiamo fatto per una delle nostre applicazioni client. È stato concesso in .NET per Windows, ma gli stessi principi possono essere applicati in MAC.

    Come accennato eckesickle, se il tuo utente ha accesso a Internet (o dovrebbe), allora puoi avere un servizio web che registrerà qualche ID univoco dal computer host con la prova della data di inizio (l’indirizzo MAC è buono). Con questo, l’utente non può veramente imbrogliare il programma a meno che non rischi la sua scheda di rete ogni mese.

    Ora, se l’utente non ha accesso a Internet per qualche motivo, è ansible arrestare il programma fino a quando non si connette ad esso o utilizzare un periodo di prova. Questo file registra l’ultima volta che l’app è stata aperta. Quando Internet non è accessibile, smettiamo di scrivere il tempo (scriviamo ancora qualcosa al suo interno in modo che l’utente non si accorga che il file non è aggiornato).

    Se un utente nota che questo file contiene le informazioni e lo elimina (o lo modifica utilizzando una copia che ha), allora è necessario un modo per contrastarlo. È ansible avere un altro valore in un altro file di configurazione (crittografato sempre) e verificare la coerenza. Quello che fai se scopri che l’utente sta cercando di imbrogliare dipende da te, ma costringiamo l’utente a connettersi a Internet perché funzioni.

    Potrebbe essere eccessivo per un programma, ma funziona definitivamente.

    Al momento del download, fornire loro un numero di serie di prova. Quando inseriscono il numero di serie, collegarlo al server e ottenere le informazioni sulla scadenza (memorizzate e crittografate localmente per evitare ulteriori chiamate “telefono casa”).

    In questo modo, è abbastanza difficile per loro aggirare la finestra di 30 giorni, poiché la data di scadenza viene memorizzata in modo permanente sul server. È ansible configurarlo in modo che l’eliminazione della chiave e il reinserimento causino nuovamente la connessione dell’applicazione al server e il download della stessa data di scadenza.

    Oppure puoi farlo come fa WinZip (o usato per farlo?): Fornisci una versione di prova di 30 giorni e fai apparire uno schermo ad ogni caricamento che mostri per quanto tempo lo stai usando e i link per l’acquisto.

    Ero solito offrire una versione lite della mia app per iOS di 30 giorni che incorporava la data di installazione e le varie date dei record nel file di dati di esportazione che l’utente poteva scaricare sul suo computer.

    Se l’utente era un cheapskate e ha appena reinstallato l’edizione lite e ha provato a reimportare i dati, la logica avrebbe notato che almeno una data era precedente a 30 giorni e l’app avrebbe impostato la data di installazione prima di tale data da il file, rendendolo di nuovo scaduto.

    Nell’edizione completa a pagamento, questa logica non esisteva e il file di dati poteva essere importato facilmente.

    È stato un dolore sostenere le persone in questa migrazione dei dati (dal momento che le app sono completamente in sandbox l’una dall’altra) e alcuni altri utenti hanno ritenuto che la versione lite fosse sufficiente per loro, quindi non hanno mai aggiornato.

    Da allora ho smesso di offrire la mia edizione lite e ho appena ridotto il prezzo della versione completa. Ora i potenziali clienti devono solo pagare una piccola sum o andare a cercare software in concorrenza.

    Tutto sumto, quella era la migliore strategia per ottenere utenti paganti.

    Leggi un UUID da alcuni componenti hardware e verifica il tuo servizio web per vedere se il tuo software è già stato installato per 30 giorni all’avvio del programma?