licensing - pruebas - Software de prueba/estrategias de licencia
estrategias de pruebas de software pdf (10)
EDITAR: Puede hacer que su esquema de licencia actual sea mucho más difícil de descifrar al almacenar la información del registro en la Autoridad de seguridad local (LSA). La mayoría de los usuarios no podrán eliminar su información clave desde allí. Una búsqueda de LSA en MSDN debería darle la información que necesita.
Las opiniones sobre los esquemas de licencia varían según cada individuo, más entre los desarrolladores que los grupos de usuarios específicos (como los fotógrafos). Debe tomar una respiración profunda y tratar de ver lo que su usuario objetivo aceptaría, dada la necesidad comercial que su aplicación resolverá.
Esta es mi opinión personal sobre el tema. Habrá personas vocales que no estén de acuerdo.
La respuesta a esto depende en gran medida de cómo esperas que se use tu aplicación. Si espera que la aplicación se use varias veces al día, se beneficiará al máximo de un período de prueba muy largo (varios meses) para crear una situación de bloqueo. Para que esto funcione, deberá tener un período de gracia en el que el software advierta al usuario de que el pago será necesario en breve. Antes del período de gracia, tendrá un mayor éxito si el software no dice nada acerca del período de prueba.
Ya sea que elijas o no creas en esta afirmación tan audaz, por supuesto, es totalmente tu decisión. Pero si lo hace, debe tener en cuenta que cuanto menos se use su aplicación, más corto será el período de prueba. También es muy importante que el pago sea muy rápido y fácil para el usuario (tan poca entrada de datos y tan pocos clics como sea posible).
Si tiene dudas sobre el uso de la aplicación, debe elegir un período de prueba muy corto. Según mi experiencia, obtendrá mejores resultados si la aplicación no dice nada sobre el hecho de que está en período de prueba en este caso.
Aunque es eficaz para fines de licencia, muchas personas consideran que las funciones de "Llamar a casa" son una amenaza para la privacidad. Personalmente, no estoy de acuerdo con la idea de que esto sea perjudicial para un cliente que está dispuesto a pagar por el software que está utilizando. Por lo tanto, sugiero que se implemente un esquema de licencias donde la aplicación verifique el estado de la licencia (prueba, pago) de manera regular y ayude al usuario a pagar el software cuando sea el momento. Sin embargo, esto podría ser excesivo para una pequeña aplicación de utilidad.
Para aplicaciones de utilidad muy pequeñas o incluso simples, defiendo que el pago por adelantado sin período de prueba es el más efectivo.
En cuanto a la seguridad de la solución, debe hacerla proporcional al esfuerzo de desarrollo. En mi línea de trabajo, la seguridad es muy crítica porque hay socios y distribuidores involucrados, y porque la inversión hecha en desarrollo es muy alta. Para una aplicación de utilidad pequeña, tiene más sentido fijar el precio correcto y confiar en los usuarios honestos que pagarán por el software que satisfaga sus necesidades comerciales.
Escribí una utilidad para fotógrafos que planeo vender en línea bastante barata ($ 10). Me gustaría permitir que el usuario pruebe el software durante una semana más o menos antes de solicitar una licencia. Como se trata de un proyecto personal y el software no es muy costoso, no creo que valga la pena comprar los servicios de proveedores de licencias profesionales y estoy haciendo lo propio.
Actualmente, la aplicación busca una clave de registro que contenga una cadena cifrada que especifique cuándo expira la versión de prueba o si tienen una licencia válida. Si la clave no está presente, se crea una clave de período de prueba.
Entonces, todo lo que necesitaría hacer para obtener otra semana gratis es eliminar la clave de registro. No creo que muchos usuarios lo hagan, especialmente cuando la aplicación cuesta solo $ 10, pero me da curiosidad si hay una forma mejor de hacerlo que no sea onerosa para el usuario legítimo. Escribo aplicaciones web normalmente y no he tratado con esto antes.
La aplicación está en .NET 2.0, si eso es importante.
En este tipo de circunstancias, realmente no creo que importe lo que hagas. Si tienes algún tipo de protección, detendrá al 90% de tus usuarios. El otro 10%: si no quieren pagar por su software, encontrarán la forma de evitarlo sin importar lo que hagan.
Si desea algo un poco menos obvio, puede poner un archivo en System32 que suene como un archivo de sistema que la aplicación verifica la existencia en el lanzamiento. Eso puede ser un poco más difícil de rastrear.
Me enfrenta el mismo problema con una aplicación que estoy vendiendo a un precio muy bajo también.
Además de ofuscar la aplicación, se me ocurrió un sistema que usa dos claves en el registro, una de las cuales se usa para determinar el tiempo de instalación y la otra la clave de licencia real. Las claves se nombran oscuramente y una clave faltante indica alteración de la instalación.
Por supuesto, eliminar ambas claves y volver a instalar la aplicación volverá a iniciar el tiempo de evaluación.
Pensé que no importa de todos modos, ya que alguien que quiera descifrar la aplicación tendrá éxito en hacerlo, o encontrará una grieta por alguien que haya tenido éxito en hacerlo.
Así que, al final, solo estoy logrando el objetivo de que no sea muy fácil descifrar la aplicación, y supongo que esto evitará que el 80-90% de los clientes lo haga. Y después de todo: como la aplicación se vende a un precio muy bajo, no hay ninguna justificación para invertir más tiempo en este tema de lo que ya tengo.
No realice la evaluación en función de "días desde la instalación", sino la cantidad de días utilizados, o la cantidad de veces que se ejecutó o algo similar. Las personas tienden a descargar shareware, lo ejecutan una o dos veces y luego lo olvidan durante unas semanas hasta que lo necesiten nuevamente. Para entonces, la versión de prueba puede haber expirado y, por lo tanto, solo han tenido algunos intentos para engancharse al uso de su aplicación, aunque la hayan tenido instalada por un tiempo. El número de días / activación en cambio les permite adquirir el hábito de usar su aplicación para una tarea y también hace una venta más fuerte (es decir, usted ha usado esta aplicación 30 veces ...).
Aún mejor, limitar las características funciona mejor que el tiempo de espera. Por ejemplo, tal vez su aplicación de fotografía podría limitar al usuario a imágenes de 1 megapíxel, pero déjelos usar durante el tiempo que lo desee.
Además, considere valorar su aplicación a $ 20 (o $ 19.95). A menos que ya haya implementado un micropago (como iPhone store o XBoxLive o algo así) las personas tienden a sentir aversión por comprar cosas en línea por debajo de un cierto punto de precio (alrededor de $ 20 dependiendo del tipo de aplicación), y la gente asume de manera inconsciente algo es barato, no debe ser muy bueno. En realidad, puede aumentar su tasa de conversión con un precio más alto (hasta un punto por supuesto).
No tiene mucho sentido hacer complicados esquemas de protección. Básicamente una de dos cosas sucederá:
Su aplicación no es lo suficientemente popular, y nadie la rompe.
Tu aplicación se vuelve popular, alguien la rompe y la lanza, entonces cualquier persona sin conocimiento puede simplemente descargar esa grieta si quieren engañarte.
En el caso del n. ° 1, no vale la pena esforzarse mucho en el plan, porque puede hacer que una o dos personas adicionales compren su aplicación. En el caso del n. ° 2, no vale la pena esforzarse mucho porque alguien lo descifrará de todos modos, y el esfuerzo se desperdiciará.
Básicamente mi sugerencia es simplemente hacer algo simple, como lo que ya eres, y eso es igual de efectivo. Las personas que no quieren engañar / robar pagarán, las personas que quieran engañarlo lo harán independientemente.
Pruebe el Shareware Starter Kit. Fue desarrollado mi Microsoft y puede tener algunas otras características que desee.
Si aloja su página de inicio en un servidor que usted controla, puede hacer que la versión de prueba descargable de su software se compile automáticamente en un nuevo binario todas las noches. Esta compilación reemplazará un valor de fecha y hora codificado en su programa para cuando expire el software. De esa forma, la única forma de "hacer trampa" es cambiar la fecha en su computadora, y la mayoría de las personas no lo hará debido a los problemas que creará.
Si planea continuar desarrollando su software, podría considerar el modelo de rescate:
http://en.wikipedia.org/wiki/Street_Performer_Protocol
Básicamente, desarrolla mejoras en el software y luego solicita una cierta cantidad de donaciones antes de lanzarlas (sin ningún DRM).
Una forma de hacerlo es fácil para el usuario pero no para usted es codificar la fecha de caducidad y crear nuevas versiones del instalador de vez en cuando ... :)
Sin embargo, si fuera tú, no lo haría más avanzado de lo que ya estás haciendo. Como dices, solo cuesta $ 10, y si alguien realmente quiere descifrar tu sistema, lo hará sin importar lo complicado que sea.
Podría hacer una versión un poco más avanzada de su esquema al requerir una conexión de red y dejar que un servidor genere la clave de prueba. Si haces algo similar al signo (hash (unique_computer_id + when_to_expire)) y dejas que la aplicación compruebe con una clave pública que tu servidor ha firmado la fecha de caducidad, debería requerir un truco "real" para eludir.
De esta manera puede almacenar el lado del servidor de la identificación única y negarse a generar una fecha de caducidad más de una o dos veces. No estoy seguro de qué usar como ID único, pero debería haber alguna manera de obtener algo útil de Windows.
solo se bueno con la licencia. explique de antemano que esta es su pasión y un hijo de su trabajo. dale a la gente la oportunidad de hacer lo correcto. si alguien quiere piratearlo, eventualmente sucederá. Todavía recuerdo mi desesperación al ver mis libros en bittorrent, pero es algo con lo que tienes que lidiar. No caiga en la piratería casual (lo que está haciendo ahora suena bien) pero no paralice la cosa más allá de eso. Sigo creyendo que hay suficientes personas honestas para hacer un esfuerzo de codificación con fines de lucro que vale la pena.