Implementando um contra-relógio de 30 dias

Pergunta para desenvolvedores de indie Mac por aí:

Como faço para implementar um contra-relógio de 30 dias de maneira não-maligna? Colocar um contador nas prefs não é uma opção, já que limpar as prefs uma vez por mês não é um problema para um usuário médio. Colocar o contador em um arquivo oculto em algum lugar soa um pouco desonesto – como um usuário que eu odeio quando aplicativos borrifam meu disco rígido com arquivos randoms. Alguma ideia?

Esse problema aparece repetidamente na lista de discussão do cacau-dev e a resposta de consenso é sempre a mais simples possível. Hackers determinados quebrarão todos, menos a solução mais engenhosa. E é improvável que paguem pelo software de qualquer maneira. Escolha a solução 80/20: a solução fácil que recebe 80% de efeito para 20% de esforço. Neste caso, coloque algo em ~ / Library / Application Support / your.app.com /. Você pode nomear o arquivo de algo inocente se quiser ofuscar as coisas um pouco. Usar os padrões do usuário também é fácil.

Faça o que fizer, não use o endereço MAC ou outro ID de hardware. Usuários com um diretório pessoal de rede (por exemplo, em uma configuração de laboratório compartilhado) irão odiá-lo. Usando IDs de hardware é apenas mal.

Se alguém está tão apaixonado por seu programa que está disposto a quebrar seus limites de teste, deixe-o. O software livre não custa nada e sua boa vontade (e talvez a recomendação para os outros) vale muito.

Finalmente, escreva um software que as pessoas queiram usar e precifique-o pelo seu valor. Se o seu preço é um bom valor e as pessoas querem usá-lo, a maioria das pessoas vai pagar por isso.

Eu sugeriria implementar algumas coisas que são menos intrusivas e podem evitar que um usuário normal desinstale ou compre no período de um mês.

  1. Use uma série especial de número de série de teste que armazena a data de vencimento. Você pode usar encrpytion para armazenar data de expiração dentro do número de série.
  2. Agora crie um arquivo de configuração que armazene dados no formato encypted e contenha o número de série.

Além disso, implemente essas coisas no arquivo de configuração.

  1. Anote a hora / data sempre que o usuário iniciar o aplicativo.
  2. Observe a duração do tempo em que o aplicativo estava aberto.

Ao fazer o registro de data e hora, você pode evitar essas soluções alternativas:

  1. Se o usuário reverter a data do computador, você saberá que o aplicativo já foi executado nesse dia. Digamos que o usuário executou o aplicativo em 1 e 3 dias do mês. Agora, após 30 dias, a data é revertida e é definida como 2 do mês. Agora, por arquivo de configuração, você saberia que o aplicativo já foi executado em 1 e 3, para que o usuário tenha atrapalhado as datas no computador.
  2. Digamos que toda vez que o usuário iniciar seu aplicativo, primeiro defina a data para o quinto dia do mês. Ao registrar o tempo de execução do seu aplicativo, você verá que, se o total de horas em um dia exceder 24, o usuário estará enganado.

Certifique-se de que seu aplicativo não seja executado sem o arquivo de configuração. Então, basicamente, você envia o número de série criptografado em um arquivo ou, ao digitar o número de série, pode criar um arquivo. Como o número de série já tem a data de validade, o usuário não pode reutilizar o número de série também.

Eu não sugeriria o caminho da internet, porque as pessoas ficam chateadas quando o aplicativo tenta se conectar ao servidor todas as vezes. Além disso, pode-se suspeitar que você está tentando enviar alguns dados pessoais de usuários para seus servidores.

Uma coisa que eu gostaria de dizer: não importa o quão forte seja a técnica anti-pirataria que você usa, alguém é obrigado a quebrá-la. Você não está fazendo o seu aplicativo para esses caras. Você está fazendo o seu aplicativo para pessoas que gostariam do seu software e o comprarão alegremente. Portanto, tenha a anti-pirataria em limites sem perder os clientes genuínos, tornando sua aplicação muito intrusiva durante o período de teste. Um pensamento também diz, se o seu software está ficando rachado isso significa que ele está ficando popular também. Mais uma vez, as opiniões podem divergir e não gostaríamos de fazer uma digressão sobre estas questões.

Considere isto. Quantos usuários em potencial do seu software estão por aí, ansiosos para usá-lo solidamente pelos próximos 30 dias?

Eu suspeito que o caso mais normal é: Os usuários encontram um novo pacote de software que resolve um problema que eles tiveram em um site como o lifehacker.com. o software é baixado, jogado com brevidade, depois colocado de lado. Talvez o seu software de captura de mp3 e eles não têm nenhum CD para rasgar naquele momento. Ou eles estão apenas ocupados naquele dia, mas eles vão analisar o software “em breve”.

30 dias passam. Provavelmente mais. Só então eles compram um CD, encontram algum tipo de ‘problema’ e lembram-se, ‘aha, há aquela versão experimental que baixei! Onde eu coloquei de novo? Não importa. Sem nunca ser usado, o ‘julgamento’ expirou.

Eu não posso contar o número de ferramentas de software que caíram nesse balde para mim. O dia em que um software me é recomendado, no dia em que vejo uma crítica positiva no lifehacker, NUNCA é o dia em que realmente preciso – ou até mesmo o tempo – usar / analisar o programa que baixei e instalei.

Ter o software vencido depois de 30 dias de calendar é ruim, porque, e se alguém fizer o download dele, executá-lo uma vez e decidir que o avaliará um mês depois? Da próxima vez que eles forem lançados, um mês depois, ele dirá que expirou.

Eu ficaria limitado a 14 lançamentos, ou algo como 120 minutos de uso.

Quanto à implementação, um arquivo (oculto ou não) na pasta Preferências do usuário, com um nome ofuscado, parece ser o melhor caminho a percorrer. O arquivo não é colocado aleatoriamente no disco rígido, mas o usuário não consegue descobrir com facilidade qual arquivo será excluído.

A maneira menos malvada é pedir ao usuário para apagar o programa depois de um mês ou pagar por ele;)

Fizemos isso para um dos nossos aplicativos clientes. Concedido foi feito no .NET para Windows, mas os mesmos princípios podem ser aplicados no MAC.

Como eckesickle mencionou, se seu usuário tiver access à internet (ou deveria), então você pode ter um serviço da web que registrará um ID único do computador host com a data de início (o endereço MAC é bom). Com isso, o usuário não pode realmente enganar o programa, a menos que acerte sua placa de rede todo mês.

Agora, se o usuário não tiver access à Internet por algum motivo, você poderá encerrar o programa até que ele se conecte a ele ou use um período de carência. Este arquivo registra a última vez que o aplicativo é aberto. Quando a Internet não está acessível, paramos de escrever a hora (ainda escrevemos algo nela para que o usuário não perceba que o arquivo não está atualizado).

Se um usuário perceber que esse arquivo contém as informações e excluí-las (ou alterá-las usando uma cópia que tenha), você precisará de uma maneira de contê-las. Você pode ter algum outro valor em outro arquivo de configuração (sempre criptografado) e verificar a consistência. O que você faz se descobrir que o usuário está tentando enganar depende de você, mas forçamos o usuário a se conectar à Internet para que ele funcione.

Pode ser um exagero para um programa, mas definitivamente funciona.

No momento do download, forneça um número de série de avaliação. Quando inserir o número de série, conecte-se ao seu servidor e obtenha as informações de expiração (armazenadas e criptografadas localmente para evitar chamadas adicionais de “telefone residencial”).

Ao fazer isso dessa maneira, você dificulta bastante a navegação na janela de 30 dias, pois a data de validade é permanentemente armazenada no servidor. Você poderia configurá-lo de modo que excluir a chave e redigitá-la fizesse com que seu aplicativo se conectasse ao servidor novamente e baixasse a mesma data de validade de antes.

Ou você pode fazer como o WinZip faz (ou costumava fazer?): Fornecer uma avaliação de 30 dias e apenas uma canvas pop-up em cada carga que mostra quanto tempo você está usando e links para comprar.

Eu costumava oferecer uma edição leve de 30 dias do meu aplicativo para iOS que incorporava a data de instalação e várias datas de registro no arquivo de dados de exportação que o usuário poderia baixar para o seu computador.

Se o usuário fosse um cheapskate e apenas reinstalasse a edição lite e tentasse reimportar os dados, a lógica notaria que pelo menos uma das datas tinha mais de 30 dias e o aplicativo definiria sua data de instalação para a data anterior de o arquivo, tornando-o novamente expirado.

Na edição completa paga, essa lógica não existia e o arquivo de dados podia ser importado facilmente.

Foi uma dor apoiar as pessoas nessa migration de dados (já que os aplicativos estão completamente em sandbox uns dos outros) e alguns outros usuários sentiram que a edição lite era suficiente para eles, de modo que nunca foram atualizados.

Desde então, parei de oferecer minha edição leve e reduzi o preço da edição completa. Agora os clientes em potencial precisam pagar apenas uma pequena quantia ou encontrar algum software concorrente.

Em suma, essa foi a melhor estratégia para obter usuários pagantes.

Leia um UUID de algum componente de hardware e verifique o seu serviço da web para ver se o seu software já foi instalado por 30 dias após o lançamento do programa?