¿Debo incluir un método de autodestrucción en mis aplicaciones?

Recientemente tuve una experiencia negativa, donde el cliente saltó de la factura, pero mi intermediario ya cargó nuestro software y diseño en el servidor del cliente. El cliente resultó ser un criminal conocido y, por supuesto, cambió todas las contraseñas posibles del servidor.

Sin embargo, todavía puedo acceder al panel de administración del CMS. Lamentablemente, resulta que mi software es muy seguro. Intenté la inyección de SQL, falsifiqué la carga de imágenes, etc. Sin embargo, no puedo hackear mi propio software. De todos modos, me estoy preparando para demandar a esta persona, por lo que no es así. el problema ... Solo estoy pensando ahora, que tal vez debería haber algún método de autodestrucción de fondo. Entonces, si ocurre un caso similar, tengo la opción de eliminar el software.

Mi propia idea es ocultar alguna función en los archivos principales. Codifíquelo con base64, por lo que no sería obvio. Entonces algo como esto:

eval(base64_decode('ZWNobyAnSGVsbG8gd29ybGQhJzs=')); // echo 'Hello world!';

Y, básicamente, haga un pequeño script, que tome todos los archivos del software, chmod para asegurarse y luego los elimine.
Mis versiones más nuevas del CMS, todas tienen administradores de archivos que podría usar para hackear más fácilmente . Pero, ¿y si el acceso al panel de administración es limitado?

Para ser muy claro , esto está destinado solo para el software de la etapa de desarrollo, en mi servidor personal o en el servidor del cliente (la última parte es éticamente cuestionable). Entonces, si mi cliente debe robar mi software ... Esto no se incluirá dentro de un comercial -software.
Y para ser aún más claros , estamos hablando de esos raros trabajos independientes. Creo que es bastante lógico, que el trabajo por contrato no necesita tales métodos. Entonces, estamos hablando de esos clientes jumprisk, solo en modo de desarrollo: cuando el proyecto está listo, entonces obviamente esta sería una puerta trasera muy poco ética para tener dentro de su software.

1. ¿Éticamente es una buena idea? (Teniendo en cuenta que, obviamente, lo eliminaré, cuando el proyecto haya sido 100% y todo esté pagado)
2. ¿Alguna vez tuvieron que hackear su propio software, debido a problemas similares con los clientes?
3. ¿Alguna recomendación sobre esta idea, código y método sabio?
4. ¿Cuáles pueden ser los posibles inconvenientes o repercusiones de los scripts de autodestrucción?

Mi conclusión sobre esto

Es un poco triste, que todas las respuestas fueron dirigidas a los casos contratados. Realmente fue mi culpa, que no lo hice más claro en mi pregunta ... solo pensé, que es bastante claro, que no tiene sentido el interruptor de matar ... cuando estás protegido por el contrato.
Sin embargo, si está haciendo un trabajo por contrato ... esto debería indicarse en el contrato, esto lo hace legal, incluso dentro del propio servidor del cliente. Sin embargo, tener interruptores de interrupción dentro de mi propio servidor personal no es asunto de nadie (esto es lo que realmente quería saber).

Decidí hacer la secuencia de comandos kill-switch para mi CMS. Principalmente, porque parece un desafío interesante. Pero también, que podría usar esto para mis trabajos no contratados donde el cliente es amigo de un amigo de un amigo ... Probablemente no usaré esto en el servidor del cliente, pero ... para los casos, donde el cliente o algunos los intermediarios tienen acceso a mi servidor ... Y mi software es robado o "movido sin mi conocimiento", entonces no me pagan y cortan el acceso al software.

He leído muchos temas aquí, donde recomiendan enviar una advertencia y luego quitar la página. Bueno, vi un problema en él, como cuando estoy tratando con una persona ... que simplemente lo copiará en otro lugar (tal vez lo renueva y lo venderá) y me dice que ha sido retirado. Y además, no "apagaría el sitio", sino que lo eliminaría. Sin embargo, supongo que todavía es ilegal acceder al servidor de mis clientes y eliminarlo. O al menos, acceda a él a través del backend y no desde el FTP. Por esto les agradezco a todos ustedes que respondieron.

No soy abogada Parece que ya tiene uno para demandar a su cliente; mientras lo tengas como retenedor, recomendaría recibir sus consejos sobre esto.

Hay algunas otras preguntas en este sitio que tratan con "interruptores de interrupción" y otras formas de deshabilitar el software por el cual el desarrollador no ha recibido compensación. Por lo general, se considera una mala idea simplemente crear uno en un software "llave en mano" (donde lo desarrollará y luego transferirá todos los derechos al cliente), sin que el contrato haya estipulado esta posibilidad.

En primer lugar, si su contrato no establece específicamente que puede desactivar el software por falta de pago, o que el cliente no tiene ningún derecho sobre el software hasta que se reciba el pago completo, entonces no puede activar ningún "interruptor de apagado" sin estar en incumplimiento de contrato. En ausencia de cualquier palabra en sentido contrario, "la posesión es nueve décimas de la ley", por lo que es su software una vez que se le da la posesión, y destruirlo sería similar a dinamitar un nuevo edificio de oficinas que le habría construido si no lo hiciera. No lo pagues.

El segundo punto sigue; cualquier contrato que ofrezca a cualquier cliente debe tener una cláusula en el sentido de: "Transferencias de propiedad intelectual sobre la satisfacción del contrato" . Eso significa que incluso si le ha dado una copia del software para que lo use, hasta que le pague la totalidad, no es el propietario. Esto le daría el derecho de deshabilitar su o cualquier copia del software por cualquier motivo hasta que se haya recibido el pago completo, porque sigue siendo suyo y puede hacer lo que quiera. Ahora, ha incumplido el contrato, y usted no lo ha hecho, por lo que el caso es MUCHO más fácil para su abogado y, mientras tanto, su cliente no obtiene ningún beneficio de sus bienes mal adquiridos.

La analogía con un contratista de edificios es válida: una vez que un edificio en construcción puede protegerse contra la entrada ilegal, lo es, y el contratista generalmente conservará todas las copias de todas las llaves de las instalaciones hasta que el trabajo esté completo y aprobado, y pago recibido en su totalidad. Incluso después de que se entregan las llaves, si el pago no se cumple, puede imponer un derecho de retención sobre la propiedad y, en el extremo, recuperarla. Lo mismo es cierto aquí; puede darle al cliente una clave para ingresar al software, pero tiene la clave "maestra", y él no tiene acceso administrativo hasta que le paguen en su totalidad. Si puede entrar ahora y no le paga, simplemente puede "cambiar las cerraduras" y bloquearlo del software.

Sin embargo, usted le ha dado a su cliente la clave "maestra" del software, y él se fue y cambió todas las cerraduras para que ahora USTED no pueda ingresar. Esa no es la forma en que debería funcionar. Todavía puede reclamar daños, pero mientras tanto, su cliente corrupto puede usar el software, copiarlo en otro lugar (eso es algo importante que no le puede pasar a un contratista; si recupera su edificio, no tiene que preocuparse de que usted he hecho una copia gratuita exacta en otro lote), etc. Básicamente, su único remedio es hacer cumplir el pago en su totalidad, porque no puede garantizar que ha reclamado todas las copias del software. Probablemente no estaría contento de recuperar su software incluso si pudiera garantizar que no tuviera más copias; Es probable que sea un trabajo personalizado que no puede simplemente dar vuelta y vender a otra persona.

Comprenda que, independientemente de sus derechos sobre el software, sus datos le pertenecen. No puedes tocarlo. Puedes detener su acceso al software que construiste, pero si destruyes sus datos, es como quemar sus posesiones después de cambiar el edificio que lo construiste por el que no pagó. No tiene ningún derecho sobre esos datos, y debe dejarlos intactos en su computadora, o si no se puede acceder a los datos de manera razonable sin su software, debe eliminarlos del enredo con su software y dárselos a él en un formato utilizable (como una base de datos de consumo humano o copias impresas o electrónicas).

En concepto tienes razón. Tu ejecución está completamente mal.

Debe proporcionarle licencias de prueba que caduquen. Tras el pago completo, dele la licencia final "para siempre". Todo por adelantado y honesto.

No. Si tus clientes se enteraran, serías linchado. No es del todo seguro. Alguien, de alguna manera, descubrirá cómo desencadenarlo y, de repente, tiene la tarea de comunicarse con todos sus clientes para informarles al respecto y por qué tienen que hacer un parche de emergencia.

Si lo piratea, también se está abriendo a un proceso penal. ¿Supongo que tiene pruebas de que aún es dueño del sitio? ¿Que tienes derecho a acceder? El costo para su negocio podría ser "astronómico"

Hay alternativas aceptables. Ponga una marca de agua en el sitio para que cada página muestre un mensaje. En el pago puede eliminar la marca de agua.

Esto parece una idea fenomenalmente mala que podría potencialmente llevarte a la cárcel.

1. No es ético El mal comportamiento de su cliente no hace que sea correcto que usted piratee su sistema.
2. Es ilegal. Esto ha sucedido antes , con malos resultados para las partes infractoras.
3. Carece de sentido. ¿Qué harías con esta puerta trasera que no te metería en problemas? ¿Chantajearías al cliente?
4. Es tonto. Incluso si pudiera hacer esto sin quedar atrapado, los riesgos potenciales superan con creces cualquier ganancia posible.

Por favor no pregunte a los programadores, pregúntele a un abogado. Me imagino que al menos querrías incluir una cláusula en tu contrato que diga que tienes derecho a hacer lo que tu pregunta contempla hacer. (¿La cláusula de "daño irreparable" de algunos contratos no le permite obtener una orden judicial para cerrar el software inmediatamente hasta que la corte tenga la oportunidad de resolverlo?) Creo que una orden judicial sería mucho más segura para usted que un bomba de código (que podría considerarse criminal, si un tribunal determina que usted no es el propietario del software, podría ser la destrucción de la propiedad, en los EE. UU. posiblemente podría caer en las secciones de cifrado digital de la Ley del Milenio Digital, etc.) imagine ganar daños en un tribunal civil y aún ser condenado en un tribunal penal).

Las reglas variarán según el lugar donde usted y su cliente vivan y operen, por lo que realmente creo que querrían un abogado.

¿Éticamente es una buena idea?

Absolutamente no. No solo te hace parecer poco profesional para los clientes honestos y honestos, sino que siento que también es perjudicial para la profesión en general. Los ingenieros de software tienen responsabilidades con su cliente o empleador, incluida la entrega de software de la más alta calidad. Si hubiera una disputa sobre pagos o contratos, existen canales apropiados. Reducir la calidad de su software no es un canal apropiado.

¿Alguna vez han tenido que hackear su propio software, debido a problemas similares con los clientes?

Nunca, aunque nunca he realizado trabajos por contrato o independientes. Siempre he sido empleado de una organización más grande (que, en algunos casos, estaba trabajando bajo un contrato). Para mí, el pensamiento es impensable. Prefiero entregar software al que me enorgullece atribuir mi nombre y ser engañado por un pequeño porcentaje de clientes que reducir la calidad de mi software, así como mis responsabilidades éticas con los usuarios del sistema.

¿Alguna recomendación sobre esta idea, código y método sabio?

No lo hagas

¿Cuáles pueden ser los posibles inconvenientes o repercusiones de los scripts de autodestrucción?

Además de los obvios problemas éticos, me preocuparían los problemas legales. No estoy seguro de si sabotear tu propio trabajo es legal, e incluso si lo es, puede que no sea así.

Simplemente implemente un módulo de licencia con licencias de tiempo limitado que deshabilitará el software al expirar. Esta es una práctica bien conocida en la industria del software y sus clientes no deberían objetarla, ya que eliminará la limitación después.

Esto también puede ser útil cuando desea limitar las funciones y ofrecer diferentes versiones de su producto.

Los interruptores de muerte simplemente tienen demasiados riesgos y no valen la pena.

Una característica secreta de autodestrucción es una idea horrenda . Sí, serás inteligente y tendrás la oportunidad de pegarlo a un cliente horrible en el futuro, pero es más problemático de lo que vale.

1. Aún no se te pagará por el trabajo que has hecho. Sí, la otra persona no usará su código; pero igual sufrirás falta de pago. ¿Crees que algún criminal decidirá pagarle a la persona que ya derribó su sitio una vez de forma remota? Encontrarán algunos nuevos tontos para hacer su sitio gratis.

2. La utilización de la secuencia de autodestrucción lo hace responsable de sus propios problemas legales. Dependiendo de las jurisdicciones, podría verse fácilmente que piratea / destruye sus datos (cuando estaban a punto de pagar y tenían muchas circunstancias atenuantes por las que no pagaron antes). Incluso si no es condenado / demandado con éxito, aún puede pagar importantes honorarios legales y tener muchos más problemas de lo que vale.

3. ¿Qué sucede si algún cliente que paga paga su código más tarde (o tiene un amigo de CS que lo examinó para hacer un pequeño ajuste), ve la función con una parte extraña de base64, es como esto, intenta ejecutarlo y elimina accidentalmente la aplicación web (y lo hace mientras estás de vacaciones, así que lleva un tiempo arreglarlo)? ¿O publica un montón de críticas públicas sobre usted en todas partes que indican que no es ético y deja puertas traseras en su trabajo? Claro que puede eliminarlo del producto terminado después de que paguen, pero con VCS pueden buscar fuentes más antiguas o no quererlo en su servidor después de que hayan pagado (y eso sería una conversación incómoda; sí, necesito una cuenta nuevamente, porque no tengo No eliminé la puerta trasera secreta de autodestrucción).

4. ¿Qué pasa si el criminal hace una copia de seguridad de sus datos? Eliminas su servidor web con una puerta trasera secreta, el sitio está desconectado durante un día o dos mientras ellos (o un amigo) encuentran la función ofensiva de la puerta trasera y está de nuevo en línea.

En el futuro, haga que las personas firmen un contrato simple, le paguen por etapas y no permita que el código abandone el servidor de desarrollo y la computadora que solo usted controla hasta que le paguen. (Si necesitan que esté en vivo antes de que termine todo el trabajo; asegúrese de que hayan pagado aproximadamente la fracción de código que se está volviendo en vivo). Si quieren ver el trabajo como está en desarrollo, pídales que le den algunas direcciones IP que abrirá su firewall para su servidor de desarrollo (y tal vez con un CNAME inteligente para el efecto deunpaid_work_in_development.example.com) No brinde garantías del tiempo de actividad de su servidor de desarrollo, y si está recibiendo mucho más tráfico del que debería (por ejemplo, encuentra que están redirigiendo a muchas personas a su sitio) simplemente cierre el firewall hasta que paguen. Si necesitan contribuir con contenido a su servidor web, haga que le envíen un correo electrónico con las sugerencias de contenido o cree una carpeta compartida de Dropbox para ellos que solo tenga permisos para escribir en el pequeño subconjunto de archivos (bajo control VCS fuera de Dropbox) que ellos puede contribuir significativamente (por ejemplo, plantillas html).

Has hecho la pregunta equivocada. Lo que debe trabajar y mejorar no es agregar algún tipo de interruptor remoto de eliminación (agregando una vulnerabilidad que usted u otra persona puedan usar), sino solucionar su problema real, que era una forma pobre de organizar el pago y la entrega. Parece que necesita un mejor sistema de custodia (o como se llame a ese concepto donde vive).

No pierda su tiempo en un interruptor de interrupción, averigüe dónde se equivocó en la parte del negocio.

Creo que idearía algún tipo de mecanismo de licencia. Esto podría basarse en cualquier cantidad de ideas comerciales o caseras y podría hacer que el software deje de funcionar después de que la licencia haya expirado. En el momento en que el cliente acepta el sistema y lo han pagado, puede proporcionar una licencia completa que no caduca.

Este enfoque también necesita la aprobación de un abogado en su territorio, pero tiene la ventaja de que no necesita deshabilitar el software de forma remota y puede estipular que esto es parte del sistema de antemano. Sin embargo, me parece muy triste que estés tratando con personas que se niegan a pagar en primer lugar.

¿No se llama DRM? Siempre que elimine la "bomba" al recibir el pago, no veo ningún problema legal con ella. Solo asegúrese de tener un parche disponible para cubrir su trasero y demostrar que no tuvo intenciones maliciosas.

Me recuerda la disposición de la "píldora venenosa" en los artículos de incorporación de algunas empresas que se activan en caso de una adquisición hostil.

A saber, la mentalidad expresada por algunos de los otros carteles aquí me recuerda por qué algunos programadores son pisoteados todo el tiempo. Si más personas pusieran tales bombas en su código, creo que los programadores podrían recibir un pago más rápido ... No tendría absolutamente ningún problema si esta fuera la norma. A la gente le encanta robar el trabajo duro de otras personas. Período. Y si Apple, et al. pueden DRM de sus cosas, entonces creo que los programadores independientes también pueden ...

En una nota práctica, seguramente el cliente verificará sus registros, encontrará la solicitud de eliminación, restaurará el código de una copia de seguridad, eliminará el interruptor de desactivación y volverá a implementar.

Los detalles de su pregunta dejan en claro que esta sería una idea absolutamente horrible. El primer cliente que descubra dicho interruptor de interrupción (posiblemente después de que lo use y se recuperen de una copia de seguridad) publicaría el interruptor de desconexión y el hecho de que lo haya incluido en el código que les entregó. Su reputación se destruiría por completo.

Y antes de que digas "bueno, serían un latido muerto, ¿cómo van a destruir mi reputación?" Considere un escenario como este: el cliente está al día, pero uno de sus empleados toma una copia del código. Despiden a ese empleado, él mira el código, descubre el interruptor de apagado y lo usa. Adivina quién tiene la culpa? (Sugerencia: eres tú)