Devrais-je inclure une méthode selfdestruct à mes applications?

J'ai récemment eu une expérience négative, client échappé de la facture, mais mon intermédiaire a déjà téléchargé notre logiciel et notre conception sur le serveur du client. Le client s'est avéré être un criminel connu et, bien sûr, il a changé tous les mots de passe possibles du serveur.

Cependant, je peux toujours accéder au panneau d'administration du CMS. Malheureusement, il s'avère que mon logiciel est très sécurisé. J'ai essayé d'injecter du code SQL, de simuler le téléchargement d'images, etc. Cependant, je ne peux pas pirater mon propre logiciel. En tout cas, je me prépare à poursuivre cette personne en justice. le problème .. Je pense juste maintenant, qu'il devrait peut-être y avoir une méthode d'autodestruction dorsale. Donc, si des cas similaires se produisent, j'ai l'option de tuer le logiciel.

Ma propre idée est de cacher une fonction dans les fichiers core. Encodez-le avec base64, pour que ce ne soit pas évident. Donc, quelque chose comme ça:

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

Et fondamentalement, créez un petit script, qui prend tous les fichiers du logiciel, chmod pour être sûr, puis les supprime.
Mes nouvelles versions du CMS ont toutes des gestionnaires de fichiers que je pourrais utiliser pour faciliter le piratage . Mais que se passe-t-il si l'accès au panneau d'administration est limité?

Pour être très clair , cela ne concerne que les logiciels en cours de développement, sur mon serveur personnel ou sur le serveur du client (la dernière partie étant éthiquement douteuse.) Donc, si mon client doit voler mon logiciel, cela ne sera pas inclus dans une publicité. -Logiciel.
Et pour être encore plus clair , nous parlons de ces rares emplois indépendants. Je pense que c'est assez logique, que le travail contractuel n'ait pas besoin de telles méthodes. Nous parlons donc de ces clients jumprisk, uniquement en mode développement - lorsque le projet est prêt, il est évident qu’il s’agirait là d’une porte dérobée très peu éthique dans votre logiciel.

1. Ethiquement, est-ce une bonne idée? (Gardant à l'esprit que je vais évidemment l'enlever, quand le projet a été à 100% et que tout est payé)
2. Avez-vous déjà eu à pirater votre propre logiciel, à cause de problèmes similaires avec le ou les clients?
3. Des recommandations sur cette idée, code et méthode sage?
4. Quels peuvent être les inconvénients ou répercussions possibles des scripts auto-destructifs?

Ma conclusion sur ce

Est un peu triste, que toutes les réponses étaient ciblées sur les cas contractés. C'était vraiment ma faute, parce que je ne l'avais pas dit plus clairement dans ma question ... je pensais juste que c'était assez clair, qu'il n'y avait pas de raison de mettre l'interrupteur antidémarrage ... quand vous êtes protégé par le contrat.
Toutefois, si vous effectuez un travail sous contrat .., cela doit être indiqué dans le contrat - cela le rend légal, même à l'intérieur du serveur du client. Cependant, avoir des commutateurs de neutralisation à l'intérieur de mon propre serveur personnel est vraiment une affaire commerciale (c'est ce que je voulais vraiment savoir.)

J'ai décidé de faire le script kill-switch pour mon CMS. Principalement parce que cela semble un défi intéressant. Mais aussi, que je pourrais l'utiliser pour mes travaux non contractés où le client est l'ami d'un ami d'un ami .. Je n'utiliserai probablement pas cela sur le serveur du client, mais..pour les cas où le client ou certains les intermédiaires ont accès à mon serveur .. Et mon logiciel est volé ou "déplacé à mon insu", alors je ne suis pas payé et ils coupent l'accès au logiciel.

J'ai lu beaucoup de sujets ici, où ils recommandent d'envoyer un avertissement, puis d'enlever la page. Eh bien, j’y ai vu un problème, comme lorsque j’ai affaire à une personne… qui va simplement le copier ailleurs (peut-être le renommer et le vendre) et me dire que cela a été supprimé. Et aussi, je ne voudrais pas "désactiver le site", mais le supprimer. Cependant, je suppose qu’il est toujours illégal d’accéder au serveur de mes clients et de le supprimer. Ou du moins, accédez-y via le backend et non depuis le FTP. Pour cela, je remercie tous ceux qui ont répondu.

Je ne suis pas avocat. On dirait que vous en avez déjà un dans le but de poursuivre votre client; pendant que vous l'avez sur mandat, je vous recommanderais de demander son avis à ce sujet.

Il y a d'autres questions sur ce site qui traitent des "kill interrupteurs" et d'autres moyens de désactiver les logiciels pour lesquels le développeur n'a pas reçu de compensation. Il est généralement considéré comme une mauvaise idée de créer simplement un logiciel "clé en main" (où vous allez le développer puis transférer tous les droits au client), sans que le contrat n’ait stipulé cette possibilité.

Tout d’abord, si votre contrat n’indique pas expressément que vous pouvez désactiver le logiciel en cas de non-paiement, ou que le client n’a aucun droit sur le logiciel tant que le paiement n’a pas été intégralement reçu, vous ne pouvez basculer aucun "kill switch" sans être en rupture de contrat. En l'absence de mots contraires, "la possession est neuf-dixièmes de la loi", donc c'est son logiciel une fois qu'il en a la possession, et le détruire reviendrait à dynamiter un nouvel immeuble de bureaux que vous auriez construit pour lui s'il ne le possédait pas. ne payez pas pour cela.

Le deuxième point suit; tout contrat que vous proposez à un client devrait comporter une clause portant la mention suivante: "Cession de propriété intellectuelle moyennant exécution du contrat" . Cela signifie que même si vous lui avez donné une copie du logiciel à utiliser, il ne la possède pas jusqu'à ce qu'il vous paye intégralement. Cela DEVRAIT vous donner le droit de désactiver sa copie du logiciel pour n’importe quelle raison, jusqu’à ce que le paiement intégral soit reçu, car il vous appartient et vous pouvez faire ce que vous voulez. Maintenant, il a violé le contrat et vous ne l'avez pas fait. L'affaire est donc BEAUCOUP plus facile à présenter pour votre avocat. Entre-temps, votre client ne tire aucun avantage de ses biens mal acquis.

L’analogie avec un entrepreneur en bâtiment est valable: une fois qu’un bâtiment en construction peut être sécurisé contre une entrée illégale, c’est le cas, et l’entrepreneur conservera généralement toutes les copies de toutes les clés des lieux jusqu’à ce que les travaux soient terminés et signés, et paiement reçu en totalité. Même après la remise des clés, si le paiement échoue, il peut attacher un privilège sur le bien et le récupérer à la limite. La même chose est vraie ici; vous pouvez donner au client une clé pour accéder au logiciel, mais vous détenez la clé "principale", et il ne reçoit aucun accès administratif tant que vous n'avez pas été intégralement payé. S'il peut entrer maintenant et ne vous paie pas, vous pouvez simplement "changer les serrures" et le verrouiller du logiciel.

Cependant, vous avez donné à votre client la clé "principale" du logiciel, et il est parti et a changé tous les verrous afin que vous ne puissiez plus entrer. Ce n'est pas ainsi que cela devrait fonctionner. Vous pouvez toujours réclamer des dommages-intérêts, mais dans l’intervalle, votre client malhonnête peut utiliser le logiciel, le copier ailleurs (c’est un problème qui ne peut pas arriver à un entrepreneur; s’il récupère son immeuble, il n’a pas à s’inquiéter avez exactement fait une copie gratuite sur un autre lot), etc. etc. En gros, votre seul recours consiste à exiger le paiement intégral, car vous ne pouvez pas garantir que vous avez récupéré toutes les copies du logiciel. Vous ne seriez probablement pas heureux de récupérer votre logiciel, même si vous pouviez garantir qu'il n'en aurait pas d'autres copies; c'est probablement un travail sur mesure que vous ne pouvez pas vous contenter de vendre à quelqu'un d'autre.

Comprenez que quels que soient vos droits sur le logiciel, ses données lui appartiennent. Vous ne pouvez pas le toucher. Vous pouvez lui interdire l'accès au logiciel que vous avez construit, mais si vous détruisez ses données, cela équivaut à brûler ses biens après avoir transféré l'immeuble que vous avez construit pour lequel il n'a pas payé. Vous n’avez absolument aucun droit sur ces données et vous devez les laisser intactes sur son ordinateur ou, si vous ne pouvez pas accéder aux données de manière raisonnable sans votre logiciel, vous devez les retirer de l’enchevêtrement avec votre logiciel et les transmettre. lui dans un format utilisable (comme une base de données humaine, des copies imprimées ou électroniques).

En théorie, vous avez raison. Votre exécution est tout faux.

Vous devez lui fournir des licences d'évaluation qui expirent. Dès le paiement complet, donnez-lui la licence finale "pour toujours". Tout franc et honnête.

Non, si vos clients découvraient que vous seriez lynché. Ce n'est pas du tout sécurisé. Quelqu'un, certains trouveront comment le déclencher, puis vous devrez soudainement contacter tous vos clients pour leur en parler et leur expliquer pourquoi ils doivent créer un correctif d'urgence.

Si vous le piratez, vous vous ouvrez également à une procédure pénale. Je suppose que vous avez la preuve que vous êtes toujours propriétaire du site? Que vous avez le droit d'y accéder? Le coût pour son entreprise pourrait être "astronomique"

Il existe des alternatives acceptables. Mettez un filigrane sur le site afin que chaque page affiche un message. Sur paiement, vous pouvez supprimer le filigrane.

Cela semble être une très mauvaise idée qui pourrait vous conduire en prison.

1. C'est contraire à l'éthique. Le mauvais comportement de votre client ne vous permet pas de pirater son système.
2. C'est illégal. Cela s'est déjà produit auparavant , avec de mauvais résultats pour les parties en infraction.
3. C'est inutile. Que feriez-vous avec cette porte dérobée qui ne vous causerait pas de problèmes? Souhaitez-vous faire chanter le client?
4. C'est bête. Même si vous pouviez le faire sans vous faire prendre, les risques potentiels l'emportent de loin sur les gains éventuels.

S'il vous plaît ne demandez pas aux programmeurs, demandez à un avocat. J'imagine au moins que vous voudriez inclure une clause dans votre contrat stipulant que vous avez le droit de faire ce que votre question envisage de faire. (La clause "préjudice irréparable" de certains contrats ne vous permet-elle pas d'obtenir une ordonnance du tribunal pour fermer le logiciel immédiatement jusqu'à ce que le tribunal ait une chance de résoudre le problème?) Je pense qu'une ordonnance du tribunal serait beaucoup plus sûre pour vous. code bombe (ce qui pourrait être considéré comme criminel, si un tribunal concluait que vous ne possédiez pas le logiciel, il pourrait s'agir d'une destruction de propriété. Aux États-Unis, cela pourrait tomber sous le coup du cryptage numérique du Digital Millennium Act, etc. imaginez obtenir des dommages-intérêts devant un tribunal civil et toujours condamné devant un tribunal pénal).

Les règles varient en fonction du lieu de résidence et d'exploitation de votre client et vous, donc je pense vraiment que vous voudriez un avocat.

Ethiquement, est-ce une bonne idée?

Absolument pas. Cela ne vous rend pas seulement peu professionnel aux yeux de clients honnêtes et honnêtes, mais j'estime que cela nuit également à la profession dans son ensemble. Les ingénieurs en logiciel ont des responsabilités envers leurs clients ou leurs employeurs, notamment en fournissant des logiciels de la plus haute qualité. En cas de différend sur le paiement ou les contrats, il existe des canaux appropriés. Réduire la qualité de vos logiciels n’est pas un canal approprié.

Avez-vous déjà eu à pirater votre propre logiciel, à cause de problèmes similaires avec le ou les clients?

Jamais, même si je n’ai jamais travaillé à contrat ou à la pige. J'ai toujours été employé par une grande entreprise (qui, dans certains cas, travaillait sous contrat). Pour moi, la pensée est impensable. Je préférerais proposer des logiciels pour lesquels je suis fier d’avoir attribué mon nom à un petit pourcentage de clients et être trompés plutôt que de réduire la qualité de mes logiciels ainsi que mes responsabilités éthiques vis-à-vis des utilisateurs du système.

Des recommandations sur cette idée, code et méthode sage?

Ne le fais pas.

Quels peuvent être les inconvénients ou répercussions possibles des scripts auto-destructifs?

Outre les questions éthiques évidentes, je m'inquiéterais des problèmes juridiques. Je ne sais pas si saboter votre propre travail est légal, et même si c'est le cas, utiliser un tel exploit pourrait ne pas l'être.

Il suffit de mettre en place un module de licence avec des licences limitées dans le temps qui désactivent le logiciel à l’expiration. Il s’agit d’une pratique bien connue dans l’industrie du logiciel et vos clients ne doivent pas s’y opposer car vous supprimerez la limitation ultérieurement.

Cela peut également s'avérer utile lorsque vous souhaitez limiter les fonctionnalités et proposer différentes versions de votre produit.

Les commutateurs de neutralisation comportent trop de risques et n'en valent pas la peine.

Une fonctionnalité secrète d’autodestruction est une idée horrible . Oui, vous serez intelligent et aurez peut-être l’opportunité de le coller à un client horrible à l’avenir, mais sa façon de faire risque de causer plus de problèmes que sa valeur.

1. Vous ne serez toujours pas payé pour le travail que vous avez accompli. Oui, l'autre personne n'utilisera pas votre code. mais vous subirez toujours le manque de paiement. Vous pensez qu'un criminel décidera de payer la personne qui a déjà fait descendre son site une fois à distance? Ils trouveront un nouveau type pour rendre leur site gratuit.

2. L'utilisation de la séquence d'autodestruction vous rend responsable de vos propres problèmes juridiques. Selon les juridictions, vous pourriez facilement être perçu comme un piratage / destruction de leurs données (au moment où ils étaient sur le point de payer et disposaient de nombreuses circonstances atténuantes expliquant pourquoi ils ne payaient pas auparavant). Même si vous n'êtes pas reconnu coupable / poursuivi avec succès, vous pouvez toujours payer des frais juridiques considérables et avoir bien plus de problèmes que sa valeur.

3. Que se passe-t-il si un bon client payant parcourt votre code ultérieurement (ou a un ami CS qui vient de le parcourir pour effectuer un ajustement mineur), voit la fonction avec une partie bizarre de base64, ressemble à ce que ça donne, tente de l'exécuter et supprime accidentellement l'application Web (et le fait pendant que vous êtes en vacances alors ça prend un peu de temps à réparer)? Ou publie-t-il de nombreuses critiques publiques vous déclarant que vous êtes contraire à l'éthique et que vous laissez derrière vous dans votre travail? Bien sûr, vous pouvez le retirer du produit fini une fois le paiement effectué, mais avec VCS, ils peuvent consulter une source plus ancienne ou ne pas vouloir vous connecter à leur serveur une fois le paiement effectué (ce serait une conversation difficile; oui, j’ai besoin d’un compte à nouveau, car je ne pas supprimé la backdoor secrète auto-destruction).

4. Et si le criminel sauvegardait ses données? Vous supprimez leur serveur Web avec une porte dérobée secrète, le site est déconnecté pendant un jour ou deux pendant qu’ils (ou un ami) trouvent la fonction de porte dérobée de la fonction incriminée et sa mise en ligne.

À l'avenir, demandez aux gens de signer un simple contrat, de vous payer par étapes et de ne pas laisser le code quitter le serveur de développement et l'ordinateur que vous êtes seul à contrôler jusqu'à ce que vous ayez été payés. (S'ils ont besoin d'être en direct avant la fin du travail, assurez-vous qu'ils ont à peu près payé la fraction de code qui devient en cours d'exécution). S'ils veulent voir le travail en cours de développement, demandez-leur de vous donner quelques adresses IP, qui ouvriront votre pare-feu pour votre serveur de développement (et peut-être avec un CNAME intelligent qui produira l'effetunpaid_work_in_development.example.com). Ne donnez aucune garantie quant à la disponibilité de votre serveur dev, et si vous obtenez beaucoup plus de trafic que nécessaire (par exemple, vous constatez qu'ils redirigent de nombreuses personnes vers votre site), fermez le pare-feu jusqu'à ce que vous payiez. S'ils ont besoin de contribuer du contenu à votre serveur Web, envoyez-les par e-mail avec les suggestions de contenu ou créez-leur un dossier partagé qui ne dispose que des autorisations pour écrire sur le petit sous-ensemble de fichiers (sous contrôle VCS en dehors de Dropbox). peut contribuer de manière significative à (par exemple, les modèles HTML).

Vous avez posé la mauvaise question. La chose à améliorer et à améliorer n’est pas d’ajouter une sorte de kill-switch distant (en ajoutant une vulnérabilité que vous ou une autre personne pouvez utiliser), mais de résoudre votre problème réel, qui était une mauvaise façon d’organiser le paiement et la livraison. On dirait que vous aviez besoin d'un meilleur système d'entiercement (ou peu importe, un tel concept s'appelle où vous habitez).

Ne perdez pas votre temps sur un kill-switch, déterminez où vous avez tout gâché dans la partie transaction.

Je pense que je mettrais au point un mécanisme de licence. Cela pourrait être basé sur un nombre illimité d'idées commerciales ou maison et pourrait empêcher le logiciel de fonctionner après l'expiration de la licence. Au moment où le système est accepté par le client et que celui-ci a payé, vous pouvez fournir une licence complète qui n’expire pas.

Cette approche doit également être approuvée par un avocat de votre territoire, mais présente l’avantage de ne pas désactiver le logiciel à distance et vous pouvez spécifier qu’il fait partie du système à l’avance. Cependant, il me semble très triste que vous ayez affaire à des personnes qui refusent de payer en premier lieu.

N'est-ce pas appelé DRM? Tant que vous retirez la "bombe" après avoir reçu un paiement, je ne vois aucun problème juridique avec cela. Assurez-vous simplement que vous disposez d'un correctif pour couvrir votre cul et montrer que vous n'avez pas d'intention malveillante.

Cela me rappelle la disposition relative à la «pilule empoisonnée» contenue dans les statuts de certaines sociétés qui sont activés en cas de prise de contrôle hostile.

En effet, la mentalité exprimée par certaines des autres affiches ici me rappelle pourquoi certains programmeurs se font piétiner tout le temps. Si plus de gens ajoutaient de telles bombes dans leur code, je pense que les programmeurs pourraient être payés plus rapidement ... Je n'aurais absolument aucun problème si c'était la norme. Les gens aiment voler le dur labeur des autres. Période. Et si Apple, et al. peut DRM l'enfer de leurs trucs, alors je pense que les programmeurs indépendants peuvent aussi ...

Sur une note pratique, le client vérifierait sûrement ses journaux, trouverait la demande de destruction, restaurerait le code à partir d’une sauvegarde, supprimerait le commutateur de neutralisation et le redéployerait.

Les détails de votre question montrent clairement que ce serait une idée absolument horrible. Le premier client à découvrir un tel commutateur d'arrêt (éventuellement après l'avoir utilisé et avoir récupéré après une sauvegarde) le publierait ainsi que le fait que vous l'aviez inclus dans le code que vous lui aviez fourni. Votre réputation serait alors complètement détruite.

Et avant de dire "bien, ils seraient un mauvais payeur, comment vont-ils détruire ma réputation?" Considérez un scénario comme celui-ci: le client est en règle, mais l'un de ses employés prend une copie du code. Ils congédient cet employé, il examine le code, calcule l'interrupteur antidémarrage et l'utilise. Devinez qui est blâmé? (Indice: c'est vous.)